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: dev-unsubscribe porting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org
|