In article <[EMAIL PROTECTED]>, David Abrahams <[EMAIL PROTECTED]> 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: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
