From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-03-22 15:14:41
In article <uwuirsbc8.fsf_at_[hidden]>, David Abrahams
>> 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
>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().
>> 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
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
>>>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
>> 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
>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 Henney phone: +44 117 942 2990
mailto:kevlin_at_[hidden] mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk