Boost logo

Boost :

From: Ross Smith (ross.s_at_[hidden])
Date: 2001-05-27 21:37:12


Up until recently, GCC had no <sstream> header in its normal
configuration (i.e. unless you added a 3rd-party library). The current
boost/config.hpp contains (edited to show only the relevant bits):

# if defined __GNUC__
# if __GNUC__ == 2 && __GNUC_MINOR__ <= 97
# if !defined(_CXXRT_STD) && !defined(__SGI_STL_OWN_IOSTREAMS)
# define BOOST_NO_STRINGSTREAM
# endif
# endif
# endif

The third quoted line I presume is checking for 3rd party libraries;
__SGI_STL_OWN_IOSTREAMS checks for the SGI library and presumably
STLPort as well; I have no idea what _CXXRT_STD comes from.

The problem with this now is that the current release, GCC 2.95.3, does
contain a working <sstream> out of the box. Unfortunately there's no
obvious way to distinguish between 2.95.3 and 2.95.[012]; GCC offers no
predefined macro for the third-level version number.

My current "solution" to this (in the Boost contribution I'm working on)
is to just go ahead and use <sstream> without bothering to check for
BOOST_NO_STRINGSTREAM and tell anyone using GCC less-than-2.95.3 to
upgrade. This is sort of within the spirit of Boost but not entirely
satisfactory.

I can see three possible courses, none of which are really satisfactory:

(1) The status quo. Leave BOOST_NO_STRINGSTREAM wrongly defined for GCC
2.95.3, and rely on the impending release of GCC 3.0 to make the problem
go away. It won't do so quickly -- a lot of current GCC 2.95.3 users are
going to wait for other people to find the bugs first.

(2) Change config.hpp so BOOST_NO_STRINGSTREAM is only defined for
versions less than 2.95. This wrongly leaves it undefined for GCC
2.95.[012]. I have no idea how many people that might affect, or how
many of them would have a problem with upgrading to 2.95.3.

(3) Go on a scavenger hunt through GCC's library headers trying to find
a macro somewhere that exists in 2.95.3 but not in 2.95.[012], or vice
versa, and use that to distinguish them. It's a horrible hack, and would
probably result in config.hpp polluting the namespace with God knows
what else from an unrelated header, but it may be workable.

-- 
Ross Smith <ross.s_at_[hidden]> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk