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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-03-22 14:11:14

>From: "David Abrahams" <dave_at_[hidden]>

> Terje Slettebø <tslettebo_at_[hidden]> 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