Dean Michael Berris wrote:
On Wed, Dec 8, 2010 at 11:07 AM, Stefan Teleman <stefan.teleman@gmail.com> wrote:
Hi. My answers inline.
On Tue, Dec 7, 2010 at 20:41, Dean Michael Berris <mikhailberis@gmail.com> 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