Boost logo

Boost :

From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-08-23 05:32:41


>(1) The macro BOOST_NO_INTEGRAL_INT64_T is listed under "Macros that
>describe defects", i.e. macros that are only defined if a feature of the
>C++ standard is missing. int64_t is not part of the C++ standard (it's
>part of the C99 standard, I think), so this macro doesn't belong here.
>It's listed again further down, under "Boost informational macros", so I
>suspect its inclusion in the earlier section is just a cut-and-paste
>error rather than a misunderstanding of the standard.

yep, that's a mistake, cut and paste leaves you brain dead after a while
;-)

>(2) I brought this one up before: BOOST_NO_STRINGSTREAM is defined for
>GCC 2.95.3, which does have stringstreams (not 100% conforming, but no
>worse than the rest of its iostream library, which seems to be
>acceptable to Boost). The problem here is that previous 2.95.x versions
>didn't have them, and (before 3.0) GCC provided no way to detect the
>third part of the version number.
>
>There doesn't seem to be any "under the counter" way of detecting the
>difference, either. I have both 2.95.2 and 2.95.3 installed on this box,
>and some work with diff on their respective include directories shows
>nothing that could be detected by the preprocessor (apart from
><sstream>, the only changes are a few small tweaks to deque and rope).
>
>I suspect that most people who were using 2.95.[0-2] have now updated to
>2.95.3 or 3.x, or could do so painlessly. I suggest that it's reasonable
>now to define BOOST_NO_STRINGSTREAM only for GCC <2.95, and ask anybody
>still using 2.95.[0-2] to upgrade, rather than unnecessarily crippling
>the library when used with 2.95.3.

I was going to argue the point on that one, but on reflection 2.95.3 has
been out for a while now, and gcc users can always run the configure script
if they insist on using an earlier version - so I think I agree on that.

- John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/


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