Re: [boost] MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)

From: David Abrahams (dave_at_[hidden])
Date: 2003-03-22 07:58:17

Terje Slettebø <tslettebo_at_[hidden]> writes:

>>From: "David Abrahams" <dave_at_[hidden]>
>
>> Terje Slettebø <tslettebo_at_[hidden]> writes:
>>
>> >> C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) :
> warning
>> > C4512: 'no_lexical_conversion<class std::basic_string<char,struct
>> > std::char_traits<char>,class std::allocator<char> >,long>' : assignment
>> > operator could not be generated
>> >
>> > This is due to that it stores a const std::string object, describing the
>> > exception
>>
>> Are you saying that you have defined an exception with a std::string
>> member?  That's VERY bad!  Throwing that exception can lead directly
>> to termination!
>
> You mean if the exception itself throws during construction or copying?

Yes.

> I've tried the program below on Intel C++ 7.0 and MSVC 6, and I haven't got
> it to call terminate(). It may be that it doesn't handle exceptions
> correctly, though.

Because you are not running in a low-memory condition.

> As it stands, it prints "Exception - Constructor", as it throws an exception
> in the constructor of the Exception exception. If the throw-statement in the
> constructor is commented out, it prints "Exception - Exception", apparently
> not invoking the copy constructor when throwing the exception (which it's
> allowed to).

Irrelevant.  A program that invokes undefined behavior may appear to
work fine also.

>> What's wrong with char const*?
>
> You mean storing the string as a character array? 

No, I mean not storing the string at all (char const* is not an
array), but storing an array is another option.

> Sure, that's possible, and I see that STLPort do it, and it's
> probably safer, as you say. It does mean you have to specify the
> maximum string length in advance, though. As "no_lexical_conversion"
> what() prints out the source and target types, it may truncate long
> type names.

There's no guarantee you have readable names anyway.  Finally, you
should never format exception messages at the throw point.  An
exception whose what() needs to print type names should store the
typeids and put the formatting logic in what().

Damn, maybe I need to update more/error_handling.html 

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com