Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
At Saturday 2003/03/22 13:11, you wrote: In article <[EMAIL PROTECTED]>, Terje Slettebø <[EMAIL PROTECTED]> writes > >Regarding the other MSVC 6 warning given in the original report, Gennaro >Prota has suggested using an explicit "!=", rather than relying on the >implicit conversion from pointer to bool. This also avoids using a cast, >instead. Or one could use "stream << input && true" ;-) However, I think if one is going to twist the expression of the code to satisfy the misplaced oversensitivity of VC, it may be better to be more explicit than subtle, ie "!(stream << input).fail()". that doesn't mean the same thing as if(stream << input) Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Mon, 24 Mar 2003 17:03:10 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: >Maybe you can also add an exclamation point Ahem, exclamation mark :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Sun, 23 Mar 2003 13:26:04 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > >>That sounds right. Would you like to post a proposed replacement (or >>patch) for the page as written which addresses your points? > > You embarrass me. Unintended. > I think the page is ok as long as you don't say > "during" stack unwinding; also I would prefer "could exit via an > exception" rather than "could throw". More-or-less: > > "Don't embed a std::string object or any other data member or base > class whose copy constructor could exit via an exception. That could > lead you straight from the point of throw to std::terminate()" > > Maybe you can also add an exclamation point as a pinch of sound > intimidation :-) I'm just too busy at the moment to make the edits, which is why I suggested you post a replacement. Often you'll find problems with suggested changes when viewed in context. Send me a replacement privately if you like. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 13:26:04 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >That sounds right. Would you like to post a proposed replacement (or >patch) for the page as written which addresses your points? You embarrass me. I think the page is ok as long as you don't say "during" stack unwinding; also I would prefer "could exit via an exception" rather than "could throw". More-or-less: "Don't embed a std::string object or any other data member or base class whose copy constructor could exit via an exception. That could lead you straight from the point of throw to std::terminate()" Maybe you can also add an exclamation point as a pinch of sound intimidation :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Sun, 23 Mar 2003 17:17:03 +0100, Gennaro Prota > <[EMAIL PROTECTED]> wrote: > >>the standard defines 'stack unwinding' as (15.2/3) >> >> The process of calling destructors for automatic objects >> constructed on the path from a try block to a throw-expression >> >>Does this include the 'argument' of the call expression? >> >> throw A() >> >>Certainly the expression A() is part of the throw-expression, however >>the quote above isn't particularly clear at saying whether "to a >>throw-expression" is inclusive or not. > > Now that I think about it, I believe the initial copy of the exception > object must logically be seen as a *part* of the evaluation of the > throw-expression. Otherwise, i.e. if you make it a separate step, you > either have to say that the temporary A() is not destroyed at the end > of its full expression (the throw) or say that it is destroyed before > you get a chance to copy it to a safe place. Don't you agree? That sounds right. Would you like to post a proposed replacement (or patch) for the page as written which addresses your points? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 17:17:03 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: >the standard defines 'stack unwinding' as (15.2/3) > > The process of calling destructors for automatic objects > constructed on the path from a try block to a throw-expression > >Does this include the 'argument' of the call expression? > > throw A() > >Certainly the expression A() is part of the throw-expression, however >the quote above isn't particularly clear at saying whether "to a >throw-expression" is inclusive or not. Now that I think about it, I believe the initial copy of the exception object must logically be seen as a *part* of the evaluation of the throw-expression. Otherwise, i.e. if you make it a separate step, you either have to say that the temporary A() is not destroyed at the end of its full expression (the throw) or say that it is destroyed before you get a chance to copy it to a safe place. Don't you agree? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 08:11:02 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: >> - "Don't embed a std::string object or any other data member or base >> class whose copy constructor could throw an exception. That could lead >> to termination during stack unwinding." >> >> I think you meant *before* (any) stack unwinding (unless you are >> thinking to catch by value, but that's highly unlikely) > >I don't actually know whether it's before or after, but it's at the >stage described by 15.1/3, so I'll clarify that. Hmmm... let's ignore the possibility to omit the copy for a moment: the standard defines 'stack unwinding' as (15.2/3) The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression Does this include the 'argument' of the call expression? throw A() Certainly the expression A() is part of the throw-expression, however the quote above isn't particularly clear at saying whether "to a throw-expression" is inclusive or not. I'm inclined to think that it is inclusive, in principle. Maybe you know something, from the committee meetings or from the standard, that contradicts this view? > [...] >I just copied the official reference text, and never knew where that >number came from. Is it really a volume number? So I guess :-) The linked to page has, at its bottom, the following "Series: Lecture Notes in Computer Science. Volume. 1766" That's itself a link and if you follow it you find a long list with one of the entries being "Volume. 1766: Jazayeri, M.; Loos, R. G.K.; Musser, D. R., (Eds.) Generic Programming" >Thanks for your remarks! Thanks to you :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > >>David Abrahams <[EMAIL PROTECTED]> writes: >> >>> Damn, maybe I need to update more/error_handling.html >> >>Done. > > Just some notes: > > - "Don't embed a std::string object or any other data member or base > class whose copy constructor could throw an exception. That could lead > to termination during stack unwinding." > > I think you meant *before* (any) stack unwinding (unless you are > thinking to catch by value, but that's highly unlikely) I don't actually know whether it's before or after, but it's at the stage described by 15.1/3, so I'll clarify that. > - "Similarly, it's a bad idea to use a base or member whose ordinary > constructor might throw, because, though not fatal, you will report a > different exception" > > Of course it *may* be fatal as well; it's just /not necessarily/ so. > It may not lead you straight to terminate (if you have a handler for > the different exception) but can in practice put the program in a > disastrous state. OK, I guess. In general a well-written program won't enter a disastrous state if you throw exception A instead of exception B at any given point. That's part of the reason exception-specifications aren't worth the trouble. I can change it to "though it may not be fatal" without feeling like a fraud. > Minor: > > - In section "What About Programmer Errors?" there's a little typo: > "neccessary" (two 'C's) > > - at the beginning of the paper, there's a link to 'Generic > Programming, Proc. of a Dagstuhl Seminar...' I was about to report the > error in the "date" (1766) :-) Maybe it would be better to write > "Volume 1766"? I just copied the official reference text, and never knew where that number came from. Is it really a volume number? Thanks for your remarks! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >David Abrahams <[EMAIL PROTECTED]> writes: > >> Damn, maybe I need to update more/error_handling.html > >Done. Just some notes: - "Don't embed a std::string object or any other data member or base class whose copy constructor could throw an exception. That could lead to termination during stack unwinding." I think you meant *before* (any) stack unwinding (unless you are thinking to catch by value, but that's highly unlikely) - "Similarly, it's a bad idea to use a base or member whose ordinary constructor might throw, because, though not fatal, you will report a different exception" Of course it *may* be fatal as well; it's just /not necessarily/ so. It may not lead you straight to terminate (if you have a handler for the different exception) but can in practice put the program in a disastrous state. Minor: - In section "What About Programmer Errors?" there's a little typo: "neccessary" (two 'C's) - at the beginning of the paper, there's a link to 'Generic Programming, Proc. of a Dagstuhl Seminar...' I was about to report the error in the "date" (1766) :-) Maybe it would be better to write "Volume 1766"? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 20:11:23 +, Kevlin Henney
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Terje Slettebø
><[EMAIL PROTECTED]> writes
>>
>>Regarding the other MSVC 6 warning given in the original report, Gennaro
>>Prota has suggested using an explicit "!=", rather than relying on the
>>implicit conversion from pointer to bool. This also avoids using a cast,
>>instead.
>
>Or one could use "stream << input && true" ;-) However, I think if one
>is going to twist the expression of the code to satisfy the misplaced
>oversensitivity of VC, it may be better to be more explicit than subtle,
>ie "!(stream << input).fail()".
That's fine too. Of course these are style/personal-taste issues. I'm
sure there's someone claiming that !! is clearer :-) More to the
point, I just suggested the way I *generally* use to shut up VC in
such cases; it' obvious that !(expr).fail() is something rather
stream-specific, whereas an explicit compare with != works any time
you have a boolean conversion.
The typical case where that warning appears with VC++ is when you
attempt to return directly the result of an API call that returns a
BOOL from a function that returns bool; e.g.:
bool IsThereAMouseHere() {
return ::GetSystemMetrics(SM_MOUSEPRESENT);
}
In that case an explicit compare with FALSE seems reasonable.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
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.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
In article <[EMAIL PROTECTED]>, Terje Slettebø <[EMAIL PROTECTED]> writes > >Regarding the other MSVC 6 warning given in the original report, Gennaro >Prota has suggested using an explicit "!=", rather than relying on the >implicit conversion from pointer to bool. This also avoids using a cast, >instead. Or one could use "stream << input && true" ;-) However, I think if one is going to twist the expression of the code to satisfy the misplaced oversensitivity of VC, it may be better to be more explicit than subtle, ie "!(stream << input).fail()". Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
In article <[EMAIL PROTECTED]>, Terje Slettebø <[EMAIL PROTECTED]> writes > >Storing a couple of type members is not enough, by itself. How would a >catch-clause taking e.g. a reference to bad_lexical_cast access them? To >access the typedefs, you need to know the exact type thrown, which means you >need to know the types to begin with... Templated catch clauses, anyone? ;-) Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 11:42:39 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: >> I'm happy that std::type_info has a private copy constructor. Hadn't >> it been for that, my suggestion to use just a couple of typedefs would >> have been routinely rejected :-) > >I don't think I understand what you're saying here, exactly. Nor do I! :-) I missed somehow the context of the discussion, as I was doing many things simultaneously while also having a look at the list. Sorry for the nonsense. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Sat, 22 Mar 2003 09:52:07 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > >>Kevlin Henney <[EMAIL PROTECTED]> writes: > >>> However, the decision as to whether this should be in the 'what' string >>> is perhaps one that can be revisited. It would be feasible to avoid any >>> allocation issues at all by leaving the human readable string as general >>> as it was before and adding type_info members that described the source >>> and target types. >> >>Yes, that was my suggestion. > > I'm happy that std::type_info has a private copy constructor. Hadn't > it been for that, my suggestion to use just a couple of typedefs would > have been routinely rejected :-) I don't think I understand what you're saying here, exactly. However, I can say this: exception-handling is a *runtime* polymorphic mechanism. Compile-time polymorphism as you can achieve by carrying type information in nested typedefs is useless in a catch block. There's no reason not to store type_info references in the exception object, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 09:52:07 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Kevlin Henney <[EMAIL PROTECTED]> writes: >> However, the decision as to whether this should be in the 'what' string >> is perhaps one that can be revisited. It would be feasible to avoid any >> allocation issues at all by leaving the human readable string as general >> as it was before and adding type_info members that described the source >> and target types. > >Yes, that was my suggestion. I'm happy that std::type_info has a private copy constructor. Hadn't it been for that, my suggestion to use just a couple of typedefs would have been routinely rejected :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
