Stephan Bergmann wrote:
[...]
For Solaris (Sparc and Intel) we are not really chained to our version
of the STLport. The Sun Studio compiler comes with two "native" C++
runtimes, one is old style "Rogue Wave" which no one will want to use
any longer anyway, and the other is ... right STLport-4.5.3 ...
You mean, the relevant parts of our stlport module and the STLport
shipped with Sun Studio are compatible, so we could use the STLport
shipped with Sun Studio instead of our stlport module on Solaris?
I haven't tested it, but on the first look it looks that way. Some
nastiness may still pop up if we try it out.
Is that it, or are we also stlport abi-ed for powerpc 32bit linux ?
I guess those who drive a given port have some leeway in defining the
point in time from when on they want to stay compatible. (That is, I
have no idea for any other platform than the four that Sun Hamburg
"cares for.")
-Stephan
Anyway we should remove the usage of "non"-standard containers in
favour of TR1 containers if it's possible. That way new ports with no
binary compatibility issues will be able to use their native STL in
future. And if we ever can be ABI incompatible with all platforms ones
again we would be ready to drop the STLport for good.
For things like hash_map, a reasonable approach might be to introduce
some wrapper header (in sal) that offers a common interface that can be
satisfied by various backends, like STLport or TR1. (As mentioned before.)
Yes, we should go that way.
Heiner
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
