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

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-03-22 15:14:41

In article <uwuirsbc8.fsf_at_[hidden]>, David Abrahams
<dave_at_[hidden]> writes
>>
>> Not quite: there is a difference between the initial construction and
>> the copy. In an insufficient-memory condition with a compiler that
>> creates the exception directly, rather than creating and then copying
>> it, the exception does not become active until the constructor has
>> completed. 
>
>You don't think I know this?

It is not what you said. What you know and what you say can be two
different things :^)

>Terje throws an exception, which causes copying.  

_May_ cause copying. I am not going to dispute the fact that the code is
entitled to do so, but it is not a requirement. Simply moderating the
precision of the language, that's all.

>If the copy throws,
>you go directly to terminate().

Correct.

>> If it does not complete, I believe that there is no cause to
>> call terminate. MSVC is one such compiler, but BCC is not. In an
>> insufficient-memory condition the former will result in a bad_alloc
>> being thrown and in the latter a call to terminate.
>
>No, you could run out of memory after initial construction but during
>copying.

Err, this is what I just said.

>> Given that the workaround in Terje's code was in response to a VC6
>> limitation (static data members of templates don't initialise
>> correctly), it may make sense to conditionally compile the code so
>> that the current code is used for VC6 and Terje's original is used
>> for more capable compilers.
>
>I have serious doubts that this is the best approach.

Likewise, but my post was even-handedly trying to present the options
and how they related to the design.

>> Storing an array is not a reasonable option in this particular case,
>> given what the code is trying to achieve. It is either impractical for
>> the application if the bound is too low or can cause undefined behaviour
>> if the bound is too high. In other words, unless (or until) the standard
>> stipulates a limit it's the wrong design whichever way you look at it
>> for this situation.
>
>A limit for what?

A limit for the minimum length required to be held for the 'what'
string. IIRC, this has come up in discussion a couple of times at WG21
meetings.

>>>There's no guarantee you have readable names anyway.  
>>
>> That's a purely theoretical rather than practical consideration. In
>> practice, I believe that all of the compilers that lexical_cast works
>> under offer something relatively meaningful. 
>
>"relatively" is a relative term ;-) I guess if you don't mind reading
>GCC's mangled names then I am forced to agree.

It is not a matter of "mind", it is a matter of ability. Many compilers
produce messages of a similar quality :-> Many programmers deal with it.

>>>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().
>>
>> On the whole this is generally good advice, but it should not be
>> treated as an absolute. Both lazy and eager evaluation have their
>> place in design.
>
>Not for exception what() messages when avoidable.

In other words, what I said :-> Design recommendations are contingent
not absolute.

>> If the effect is the same, it does not matter where the string
>> is formatted. 
>
>The effect is not the same though.

Err, this is also what I said in my post a few sentences later. There
must be an echo ;-)

>> In this case, Terje's original intent was to use a static member to
>> hold the representation, which would have resulted in formatting the
>> string before the constructor, which is the critical point of
>> failure. 
>
>How can a static string hope to hold arbitrary messages containing a
>variety of type names? 

If you looked at the code you would see what Terje's original intent
was, and why this particular aspect would not have been an issue.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________