Re: [boost] Boost on Sun CC without STLPort

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
>> 12.2).
>>
> 
> 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 
that later.

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.

Jeff