Jens-Heiner Rechtien wrote:
Stephan Bergmann wrote:
Caolan McNamara wrote:
On Fri, 2007-03-02 at 09:14 +0100, Stephan Bergmann wrote:
Hi all,
Reading this, I was just wondering whether, in general, it would
make sense for completely new platforms to not use our STLport but
rather the standard libraries that come with the respective compiler
(if they are complete enough, which I assume is the case by now).
(Of course, that would mean that we have to clean up
STLport-specific constructs in our code base, but the more portable
the better, anyway.)
I'd be in favour of this. Might need a bit of work, at the moment the
configure flags "--without-stlport4" attempts to build without stlport
and for gcc sticks some "bouncer" headers into the build to bring the
gcc "ext" rope/hash_map/hash_set headers into the "std" namespace to
attempt to do this. That sort of hack may or may not be necessary for
other compilers, and it certainly needs freshening. If we were to go for
it then we can just detect the platform in configure and default one way
or the other.
So on what platforms are we chained to stlport for ABI purposes,
sparc 32bit solaris, intel 32bit windows and intel 32bit linux ?
+ intel 32bit solaris
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?
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.)
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
