Subject: Re: [boost] Boost on Sun CC without STLPort
From: Jeff Garland (jeff_at_[hidden])
Date: 2010-12-08 09:57:57
Dean Michael Berris wrote:
> On Wed, Dec 8, 2010 at 11:07 AM, Stefan Teleman
> <stefan.teleman_at_[hidden]> wrote:
>> Hi. My answers inline.
>> On Tue, Dec 7, 2010 at 20:41, Dean Michael Berris
>> <mikhailberis_at_[hidden]> wrote:
>>> Okay, as I understand it the STL that Sun uses (libCstd) is a
>>> RogueWave derived STL -- which subsequently is the same library which
>>> became Apache stdcxx. Is stdcxx the new default or is libCstd still
>>> the default with later versions of the compiler/OS?
>> Yes, libCstd is in fact a very old version of RogueWave. But it's so
>> old, it is not ABI compatible with the latest Apache stdcxx V4 (I
>> think libCstd is based on RogueWave Version 2). And it was initially
>> severely crippled due to the C++ compiler limitations in Sun Workshop
>> 5 (yes, it's that old!).The default STL library is still libCstd for
>> the Studio compilers, even for the latest versions (12, 12.1 and
> Oh darn. So I guess it's up to me to try and rebuild all the other
> libraries the app depends on to use either STLPort or Apache stdcxx.
> If that can't happen, I guess I'm DOA with using Boost on Solaris. :(
Maybe not. For a variety of reasons I've been in a position lately to try
forcing some parts of Boost to work with studio 12 (on Solaris 10) and the old
RW based stl instead of stlport. Here's some notes on that w.r.t boost 1.43.
Overall, the compiler is fine -- it has a modern front end and can handle
modern c++. It's just the old library that gets in the way. Practically
speaking this means that some basic things like shared_ptr, optional, and
tuple will work with no difficulty. Just don't try to run the tests...more on
The first issue boost build. Compiler options have to be hacked to turn off
stlport in tools/sun.jam file -- there may be a more elegant way, but I
couldn't figure it out, so I hacked it there.
One of the primary issues with the RW based library is lack of a sufficient
standard allocator (I believe the it is a missing rebind method). This is
easily worked around by simply writing your own allocator and providing it to
your favorite boost libs that need an allocator. I actually changed the boost
collection defaults in the libs we are using (things like unordered) so that
we could use them 'normally' -- basically in a forward compatible mode so we
can remove our changes later when we get to a more modern library without
impacting boost client code.
The library also lacks wide char support -- so I turned that off in
boost/config/user.hpp (BOOST_NO_STD_WSTRING and BOOST_NO_STD_WSTREAMBUF). That
helped with libraries like string_algo, regex, date-time, and serialization
which all have macros that can turn off wide char support. date-time also
needed the 'pre-133 facet' (a legacy implementation selected by defining
USE_DATE_TIME_PRE_1_33_FACET_IO) since the library I/O facets aren't really up
to snuff. This turns off some of the fancy features in date-time i/o, but
really not too bad.
For filesystem there was a tweak needed in operations.cpp. There was some
ambiguity in several places where the sun compiler wanted 0L or 0LL instead of
a plain 0.
There are probably a few more details, but my experience is that much useful
code can be enabled with a little bit of work. That said, there is risk and
effort going down this path. Many of the tests for the various libraries won't
build even if the library code will b/c tests often depend on other parts of
the std lib than the library itself and hence it's often hard to evaluate if a
library will work or not. And beyond that, sometimes there is a feature of a
lib that won't compile-- but if it's in template code (typical with boost) and
you don't use that feature you're fine. We've resorted to subsetting the
tests or writing a simple test to evaluate if a library will do what we need
it to. And note that all of what I've said is in a way preliminary -- we have
used various parts of the aforementioned libs in our own way, but most of it
isn't in full production yet. So, depending on the libs and features you need,
ymmv. Overall though, in my experience, it's been well worth it for us to do
this little bit of effort for the capabilities we've got in return.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk