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
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.; 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
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.. 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., 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