Simon Atanasyan wrote:
2006/11/28, Bjørn Roald <bjorn@4roald.org>:
James Dennett skrev:
(Unfortunately the platform on which I currently do most of my work -- Solaris, using Sun's compiler and standard library -- doesn't support much of Boost. Sun's support for boost seems to be dependent on us being able to use a binary-incompatible standard library implementation, which is not viable when needing to link with third-party proprietary libraries.)
Maybe Sun need to switch to use stlport as their default standard library for the next compiler release. This would signal which library is considered more compliant and most relevant for library vendors. Special flags should be for backward compliance, not the other way around.
We're (at Sun) discussing this suggestion. Maybe -library=stlport4 will be on by default in the next release.
I would welcome such a move.
But this won't help in that case quickly. There are a lot of third-party library developers who supplies libraries in a binary format and link it with very old std library implementation.
Indeed. But the sooner there's a move towards a relatively standards-conforming library, the sooner those developers will move too (even if it will take years). There are probably changes that could be made even without breaking binary compatibility: for example, I'm not aware of any backwards compatibility issues if the member template functions in the Rogue Wave stdlib were enabled with a future release of Sun's compilers. (Of course I could be missing a technical point, or a contractual one, or other.) On the other hand, enabling piecemeal functionality like this without the extensive effort you've put into making Boost work with the Sun CC + STLPort4 toolset probably wouldn't help all that much with getting Boost to work with Sun CC + Rogue Wave's stdlib. -- James