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 12:55:27

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

> Terje Slettebø <tslettebo_at_[hidden]> writes:
>
> >> Terje Slettebø <tslettebo_at_[hidden]> writes:
> >>
> >> > I've tried the program below on Intel C++ 7.0 and MSVC 6, and I
haven't got
> >> > it to call terminate(). It may be that it doesn't handle exceptions
> >> > correctly, though.
> >>
> >> Because you are not running in a low-memory condition.
> >
> > What difference would that make? In the example program, it throws an
> > exception from the exception constructor, effectively simulating an
> > out-of-memory exception.
>
> Replace operator new so that it throws unconditionally *after* the
> exception object is constructed.  If you try this on an implementation
> where the exception object gets copied during unwinding, it will
> terminate().  It's the copy ctor that matters in this case.

The test program also had a throwing copy constructor. However, on Intel C++
7.0, the copy was elided, so the copy didn't get tested.

> >> > 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's wrong with char const*?
> >> >
> >> > You mean storing the string as a character array?
> >>
> >> No, I mean not storing the string at all (char const* is not an
> >> array), but storing an array is another option.
> >
> > Yes, I know that, of course. However, since if you just store a
> > pointer, the string has to be allocated some other way. How would
> > you allocate it?
>
> Just use a string literal; the compiler has to allocate that as part
> of the program image.

Sure, that's what the original lexical_cast did. However, if you are to
include in the string info about the types, storing it as a string literal
is not enough.

> > As Kevlin says in another posting, the "terminate on second
> > exception",
>
> He never used that phrase.  What do you mean?

True. I was referring to "In an insufficient-memory condition the former
will result in a bad_alloc being thrown and in the latter a call to
terminate." In other words, if you throw an exception in the copy
constructor, when an exception has already been thrown, i.e. during stack
unwinding, as you also say in the updated "Error and Exception Handling"
document.

> > which I thought you alluded to in your first reply, and maybe you
> > did, may not apply at the point of construction, since it only
> > applies after the evaluation of the throw-expression. In other
> > words, if the construction fails, you only loose the first
> > exception, and it instead throws the new one.
>
> I am aware of how C++ EH works, really!

I know you are. This was mostly to try to get a common understanding, since
I was a little confused about what you meant, and therefore wrote the above,
explaining what I had meant.

> > 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?

Regards,

Terje