>From: "David Abrahams" <[EMAIL PROTECTED]> > Terje Slettebų <[EMAIL PROTECTED]> writes: > > >> >> > 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. > > > > I did not state the latter part as a general claim, which is why I said that > > eliding the copy is something it's allowed to, but not required to. Thus, > > there's no argument to consider "irrelevant". > > What I meant (though sorry I was probably too blunt about it) was that > it's irrelevant whether you actually observed termination or not, > unless you're intending for lexical_cast to work just on that compiler.
That's correct, and I meant nothing else, either. > >> > The reason the extended error type was added, was that there has > >> > been requests on this list for storing the types used in the > >> > conversion, in the exception, to make it easier to know which > >> > conversion failed. > >> > >> That's a good request, but you didn't do that, did you? > > > > Let me rephrase it: IIRC, the request was for storing information about the > > types used, not how this was to be done. Thus, whether or not this does what > > was requested depends on how to interpret the request. > > > > The suggestion to store (pointer/reference to) type_info objects doesn't > > store the types, either; it stores information about them, this time in a > > way easier for the program to use. > > > > So, I can just as well say as you say: The suggestion you said you meant > > (storing references to type_info objects) doesn't do that, either, does it? > > Ugh. As far as it's possible to store a type at all in C++, yes my > suggestion does store the types. No, it doesn't; it stores a reference to an object describing them. My version stored a string describing them. I just applied the same hair-splitting reasoning that made you categorically state that my implementation "didn't do that" (what was quoted as requested). My implementation do it just as well as your suggestion, both stores information describing the types. One is geared towards user-readable information, one is geared towards program-readable information. Agree? I wouldn't have made this such a big issue had you not claimed the implementation didn't do what was requested, when both that and your suggestion implements the request. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
