Re: [boost] lexical_cast and gcc 2.96

From: Thomas Matelich (toms-mailing-lists_at_[hidden])
Date: 2001-10-15 15:35:50

larsbj_at_[hidden] wrote:

> It seems that the stringstream provided with gcc 2.96 (the Redhat
> version), does not cut it for lexical_cast. I get strange exceptions
> that is just impossible to catch.
>
> OTOH gcc 2.96 also provides strstream, and this works ok with
> lexical_cast.
>
> I am not sure what config should be changed to fix this, but perhaps
> just a change from 95 to 96 in boost/config/stdlib/sgi.hpp:
>
> //
> // No std::stringstream with gcc < 3
> //
> #if defined(__GNUC__) && (__GNUC__ < 3) && (__GNUC_MINOR__ < 95) && !defined(__STL_USE_NEW_IOSTREAMS) || defined(__APPLE_CC__)
>    // Note that we only set this for gnu C++ prior to 2.95 since the
>    // latest patches for that release do contain a minimal <sstream>
>    // If you are running a 2.95 release prior to 2.95.3 then this will need
>    // setting, but there is no way to detect that automatically (other
>    // than by running the configure script).
> #  define BOOST_NO_STRINGSTREAM
> #endif
>
> So it seems that even if 2.95.3 and 2.96.x do provide stringstream it
> should be disabled for boost. (perhaps others have other datapoints)

I don't know your code, but I know that I use lexical_cast a lot, and around me people use RedHat's and Mandrake's unofficial
g++'s.  I tend to go by the Pragmatic Programmer rule: "select Isn't Broken" and check my code first.  My first guess is always
that check for eof() because too often I send text with 2 "words" in to be cast as, say, an int.  This causes an exception.

Perhaps it would be helpful to provide an explanation as to which part of the cast caused the exception:

if(!(interpreter << arg))
    throw bad_lexical_cast("Source Insertion");
if(!(interpreter >> result))
    throw bad_lexical_cast("Result Extraction");
if(!(interpreter >> STD ws).eof())
    throw bad_lexical_cast("Not At End Of Available Data");

an enum might be smarter.  Also would it be too much overhead to have the type_info's of the types used available in the
exception?  I tend to use one blanket catch for a lot of lexical_casts, and it gets to be a pain to track down which one threw.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
matelich_at_[hidden]
tmatelich_at_[hidden]