John Plocher writes:
> 1) What happens TODAY when I have
> 
>      A) A middleware C++ module that uses the STLPort4 Standard C++ Library
>      B) A different middleware module that uses the Apache Standard C++ 
> Library
>      and
>      C) A program that needs to use both middleware libraries?
> 
> (I would expect pain and suffering and a failed build, but I could be wrong.)

That'd be the hoped-for case.

The more likely case is that the build works just fine, but subtle
bugs and data corruption result when (say) 'program' allocates an
object using 'STLPort4' and hands it off to a function^Wmethod using
Apache.

Many of those sorts of problems just can't be detected at build time.
There's no good way to know what's "underneath" a library that you're
using -- and since it's _supposed_ to be an implementation detail of
that middleware, it's not something you'd even want to know.  And it
may change with time.

>     New C++ middleware libraries should/must use [... pick one...] in
>     order to ensure that applications can actually be built that use
>     multiple C++ modules.

That's the part that I think is missing.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to