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