Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-15 11:41:11


Paul,

I can't comment on the MSVC implementation of std::exception or
std::runtime_error since I don't have access to the implementation either.
As such, it's impossible for me to say whether the Dinkum std::exception
implementation is immune to double-destruction or not. You might try some
empirical tests with the debugger. What you need to do for your own
exception classes is usually to make sure that the first destruction will
leave their data members in such a state that a second destruction is
harmless (e.g. zero-out pointers that get deleted).

Good luck,
Dave

----- Original Message -----
From: "Paul C. Kunysch" <Illume_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 15, 2001 10:49 AM
Subject: [boost] [bpl] double destruction / exceptions

>
> Hello
>
> (from a comment in conversions.cpp:)
> re-toss the current exception so we can find out what type it is.
> NOTE: a heinous bug in MSVC6 causes exception objects re-thrown in
> this way to be double-destroyed. Thus, you must only use objects that
> can tolerate double-destruction with that compiler. Metrowerks
> Codewarrior doesn't suffer from this problem.
>
> How can I derive a class from std::runtime_error (or should I
> use std::exception?) and make it "double-destructible"?
>
> Does it matter how the "what-string" is allocated or which
> constructor is called?
>
>
> (The MSVC version of std::exception has a member "int _m_doFree;".
> I suppose this means that it tries to free the "_m_what" string
> under certain circumstances and this crashes when the exception
> is destroyed twice. I couldn't find the implementation of
> std::exception::~exception() anywhere, and the documentation
> seems to be useless to me.)
>
>
> Bye
>
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk