In article <howlettD3EKI0.5LD@netcom.com>,
J. Scott Howlett <howlett@netcom.com> wrote:

>Don't forget, though, that there is a practical difference between
>"Does the language require that X happen" and "does the compiler
>(read: the one I happen to be using) provide X". So, the simple
>comp.std.c++ answer of "yes" does not necessarily solve anyone's
>problem.

True.  Still, if the language requires it and the compiler doesn't do
it, it's a compiler/support-library bug.  This means you can pressure
the vendor to fix it, a conscientious vendor will try to do so as soon
as possible after the problem is reported, and on popular platforms
non-conscientious vendors are likely to face competition, giving you
alternative compilers that DO do it right.
--
 (My usual signature suppressed since it's not germain to this group.)

Michael McClary      mcclary@netcom.com
For faster response, address electronic mail to: michael@node.com

In article <3gp79l$nh4@booz.bah.com> Doug Judd <djudd@ads.com> writes:
>Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
>> Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
>> > Boris Boehlen <bobo@nobody.gun.de> wrote:
>> > > I'm not sure about one special thing in exception handling.
>> > > Does the compiler ensure that the destructors of any object in a
>> > > function are called when throwing an exception.
>
>However, to prevent _false_ rumors (ARM r.15.3):
>
> "As control passes from a throw-point to a handler,
>  destructors are invoked for all automatic objects
>  constructed since the try-block was entered."

Don't forget, though, that there is a practical difference between
"Does the language require that X happen" and "does the compiler
(read: the one I happen to be using) provide X". So, the simple
comp.std.c++ answer of "yes" does not necessarily solve anyone's
problem.

On a related note, I'm looking for a commercial-quality c++ compiler
for the Mac which implements exception handling and templates. I know
that Metrowerks and Symantec will eventually support them, but that
doesn't help me now.

Regards...


--
Scott Howlett
Storm Software, Inc.
howlett@netcom.com

>Hi,
>
>I'm not sure about one special thing in exception handling.
>Does the compiler ensure that the destructors of any object in a
>function are called when throwing an exception.
>
>Code sample:
>
>void f(...)
>{
>  X  x;   // Has a destructor
>  Y  y;   // Has a destructor
>
>  if (foo)
>     throw FooException;
>
>  // ...
>}
>
>Now the big question:
>
> Does the compiler call the destructors of x and y???
>
>Hope that someone could help me this.

Yes.  This is one of the basic features of exceptions.  When the exception
is thrown, the stack is traversed, and every object encountered that has a
destructor, has its destructor called.  The only exception to this (no pun
intended), is in a constructor.  If the construction is not finished, then
it is in a halfway state, and the destructor is not called for it.  Any
items created by new would need to be destructed manually.

Cliff Rayman
Rayman & Associates
Financial & Marketing Services for
Software Developers, Producers and Publishers

In <3govtf$a4p@crchh327.bnr.ca>
Jeffrey Fries P865 <pegasus1@bnr.ca> writes:

<example of code with a throw clause and question "are the destructors
called" removed>

> > It is my understanding that this is implemented using setjmp and
> > longjmp function calls in C. This point was brought up in a course
> > entitled "Object Oriented Programming Using C++" taught by Author
Reil.
> > Anyway, the bottom line is the housekeeping(calls to the destructors)
> > need to be handled by you and are not implicitly handled.
<cut>
>
> The other point to remember is the code executed on the return from
> a throw method is the code that was about to be executed before the
> throw occured.
>
> -- Later,
>    Jeff
>

wrong Wrong WRONG _WRONG_ ____WRONG____

Perhaps a quick check of a reference would held.

ARM Section 15.3 "Constructors and Destructors"

"As control, passes from a throw-point to a handler, destructors are
invoked for all automatic objects constructed sine the try-block was
entered.
  An Object that is partially constructed will have destructors executed
only for its fully constructed sub-objects".

Need I say more?

Except that the THROW and CATCH macros provided in some versions of MFC
by Mircosoft (pre VC++ V2.0) are NOT C++ exception handling (they are a
load of crud IMO).

------------------------------------------------------------------------
#include <std-disclaimer.h>
"What's a Q" - "It's a letter of the alphabet as far as I am concerned".
Richard Cox: Zergo Limited, Innovation House, Hemel Hempstead,
Herts., HP2 7DN, UK.  richardcox@cix.compulink.co.uk

In a previous posting,  (dpannett@sallie.wellesley.edu) writes:
> Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
>>
>> Boris Boehlen <bobo@nobody.gun.de> wrote:
>> >
>> > Hi,
>> >
>> > I'm not sure about one special thing in exception handling.
>> > Does the compiler ensure that the destructor of any object in a
>> > function are called when throwing an exception.
>> >
>> > Code sample:
>> >
>> > void f(...)
>> > {
>> >   X  x;   // Has a destructor
>> >   Y  y;   // Has a destructor
>> >
>> >   if (foo)
>> >      throw FooException;
>> >
>> >   // ...
>> > }
>> >
>> > Now the big question:
>> >
>> >  Does the compiler call the destructors of x and y???
>> >
>> > Hope that someone could help me this.
>> > Please send any suggestions to the following EMail address:
>> >
>> >     BOBO@nobody.gun.de
>> ---------------------------------------------------------------------
>>
>> It is my understanding that this is implemented using setjmp and
>> longjmp function calls in C. This point was brought up in a course
>> entitled "Object Oriented Programming Using C++" taught by Author Reil.
>> Anyway, the bottom line is the housekeeping(calls to the destructors)
>> need to be handled by you and are not implicitly handled.
  Although the standard demands stack unraveling and destructor calls for
exceptions, the MACROS used by MS Visual C++ to imitate exception handling
are implemented as you state with setjmp etc. This may have been the source
of confusion for you course teacher. That is also another reason to avoid
non ARM confroming C++ implementations like Visual C++.

>
> Of course, if your teacher taught you otherwise, perhaps he deserves to have
> his name mentioned in your post... (perhaps he was talking about an early
> "hacked" version of exception handling???)
>
>                         Good luck,
>
>                                 David Pannett (dpannett@wellesley.edu)

--
Bill Royds           az915@freenet.carleton.ca     C.L.B.R.R. Ag Canada
Ottawa, Ontario      ROYDSW@ncccot.agr.ca          Scientific Software Support

In article a4p@crchh327.bnr.ca, Jeffrey Fries P865 <pegasus1@bnr.ca> writes:
>Boris Boehlen <bobo@nobody.gun.de> wrote:
>>
>> I'm not sure about one special thing in exception handling.
>> Does the compiler ensure that the destructors of any object in a
>> function are called when throwing an exception.
>
>It is my understanding that this is implemented using setjmp and
>longjmp function calls in C. This point was brought up in a course
>entitled "Object Oriented Programming Using C++" taught by Author Reil.
>Anyway, the bottom line is the housekeeping(calls to the destructors)
>need to be handled by you and are not implicitly handled.

I hope the instructor didn't really say that. It is completely wrong.

He might have been talking about a way to simulate exceptions in a compiler
that doesn't support them.

The whole point of exceptions is that from the throw point to the catch
point, the stack is unwound and all constructed auto objects which have
not been destroyed are destroyed in reverse order of their construction.
The language definition requires this to happen automatically, and it is
up to the compiler and runtime system to make it happen.
---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3go57o$blb@news.rwth-aachen.de>,
Boris Boehlen  <bobo@nobody.gun.de> wrote:
>Hi,
>
>I'm not sure about one special thing in exception handling.
>Does the compiler ensure that the destructors of any object in a
>function are called when throwing an exception.
>
>Code sample:
>
>void f(...)
>{
>  X  x;   // Has a destructor
>  Y  y;   // Has a destructor
>
>  if (foo)
>     throw FooException;
>
>  // ...
>}
>
>Now the big question:
>
> Does the compiler call the destructors of x and y???

Yes!

All objects constructed in a try block are destructed in reverse
order. Think most compilers create a queue for each try
block. The elements of this queue are pointers to the objects
constructed in the corresponding try block. When an exception is
thrown the elements in this queue are desctruted starting at the
last one added to the queue (so it's a LIFO).

Gtx:


--
Name: Arnoud Martens, Utrecht, the Netherlands,  tel: +31-30-732679
E-mail: arnoudm@ijssel.xs4all.nl WWW: http://www.xs4all.nl/~arnoudm

Hi,

I'm not sure about one special thing in exception handling.
Does the compiler ensure that the destructors of any object in a
function are called when throwing an exception.

Code sample:

void f(...)
{
  X  x;   // Has a destructor
  Y  y;   // Has a destructor

  if (foo)
     throw FooException;

  // ...
}

Now the big question:

 Does the compiler call the destructors of x and y???

Hope that someone could help me this.
Please send any suggestions to the following EMail address:

 BOBO@nobody.gun.de

Boris Boehlen <bobo@nobody.gun.de> wrote:
>
> Hi,
>
> I'm not sure about one special thing in exception handling.
> Does the compiler ensure that the destructors of any object in a
> function are called when throwing an exception.
>
> Code sample:
>
> void f(...)
> {
>   X  x;   // Has a destructor
>   Y  y;   // Has a destructor
>
>   if (foo)
>      throw FooException;
>
>   // ...
> }
>
> Now the big question:
>
>  Does the compiler call the destructors of x and y???
>
> Hope that someone could help me this.
> Please send any suggestions to the following EMail address:
>
>  BOBO@nobody.gun.de
---------------------------------------------------------------------

It is my understanding that this is implemented using setjmp and
longjmp function calls in C. This point was brought up in a course
entitled "Object Oriented Programming Using C++" taught by Author Reil.
Anyway, the bottom line is the housekeeping(calls to the destructors)
need to be handled by you and are not implicitly handled.

A quick way to test this is put a print statement in your destructor
code,force the throw to be executed, and see if the message comes
out.

Hope this is helpful,
Jeff

Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
>
> Boris Boehlen <bobo@nobody.gun.de> wrote:
> >
> > Hi,
> >
> > I'm not sure about one special thing in exception handling.
> > Does the compiler ensure that the destructors of any object in a
> > function are called when throwing an exception.
> >
> > Code sample:
> >
> > void f(...)
> > {
> >   X  x;   // Has a destructor
> >   Y  y;   // Has a destructor
> >
> >   if (foo)
> >      throw FooException;
> >
> >   // ...
> > }
> >
> > Now the big question:
> >
> >  Does the compiler call the destructors of x and y???
> >
> > Hope that someone could help me this.
> > Please send any suggestions to the following EMail address:
> >
> >  BOBO@nobody.gun.de
> ---------------------------------------------------------------------
>
> It is my understanding that this is implemented using setjmp and
> longjmp function calls in C. This point was brought up in a course
> entitled "Object Oriented Programming Using C++" taught by Author Reil.
> Anyway, the bottom line is the housekeeping(calls to the destructors)
> need to be handled by you and are not implicitly handled.
>
> A quick way to test this is put a print statement in your destructor
> code,force the throw to be executed, and see if the message comes
> out.
>
> Hope this is helpful,
> Jeff
>
---------------------------------------------------------------------

The other point to remember is the code executed on the return from
a throw method is the code that was about to be executed before the
throw occured.

-- Later,
   Jeff

Yes, the compiler ensures that the destructors for y, and then x are called
when the 'throw' is done.
--
Mark Mendell
C Set ++ for AIX Development
IBM Toronto Lab
mendell@vnet.ibm.com

Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
>
> Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
> >
> > Boris Boehlen <bobo@nobody.gun.de> wrote:
> > >
> > > Hi,
> > >
> > > I'm not sure about one special thing in exception handling.
> > > Does the compiler ensure that the destructors of any object in a
> > > function are called when throwing an exception.

[ .... ]

> > [ Misleading Response #1 ]

> [ Misleading Response #2 ]


This type of questions seems more appropriate for comp.lang.c++.

However, to prevent _false_ rumors (ARM r.15.3):

 "As control passes from a throw-point to a handler,
  destructors are invoked for all automatic objects
  constructed since the try-block was entered."

- Doug

 o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
 Doug Judd
 Advanced Decision Systems (Booz-Allen & Hamilton, Inc.)
 1500 Plymouth St., Mountain View, CA 94043-1230
 djudd@ads.com, (415) 960-7450

Jeffrey Fries P865 <pegasus1@bnr.ca> wrote:
>
> Boris Boehlen <bobo@nobody.gun.de> wrote:
> >
> > Hi,
> >
> > I'm not sure about one special thing in exception handling.
> > Does the compiler ensure that the destructors of any object in a
> > function are called when throwing an exception.
> >
> > Code sample:
> >
> > void f(...)
> > {
> >   X  x;   // Has a destructor
> >   Y  y;   // Has a destructor
> >
> >   if (foo)
> >      throw FooException;
> >
> >   // ...
> > }
> >
> > Now the big question:
> >
> >  Does the compiler call the destructors of x and y???
> >
> > Hope that someone could help me this.
> > Please send any suggestions to the following EMail address:
> >
> >     BOBO@nobody.gun.de
> ---------------------------------------------------------------------
>
> It is my understanding that this is implemented using setjmp and
> longjmp function calls in C. This point was brought up in a course
> entitled "Object Oriented Programming Using C++" taught by Author Reil.
> Anyway, the bottom line is the housekeeping(calls to the destructors)
> need to be handled by you and are not implicitly handled.
>
> A quick way to test this is put a print statement in your destructor
> code,force the throw to be executed, and see if the message comes
> out.
>
> Hope this is helpful,
> Jeff
>

and then Jeffrey Fries P865 <pegasus1@bnr.ca> added:

>The other point to remember is the code executed on the return from
>a throw method is the code that was about to be executed before the
>throw occured.

!!!!!!!!

Jeff, is it possible that you misunderstood something in the C++ course that
you cite?  In any conforming implementation,

1) the destructors for x and y above are indeed called when the exception
   is thrown, and

2) the code executed on return from the thrown exception is *not* "the code
   that was about to be executed before the throw occured".  Execution will
   resume at the point *following* the original *call* to f(...), not in the
   middle of f(...) .

Of course, if your teacher taught you otherwise, perhaps he deserves to have
his name mentioned in your post... (perhaps he was talking about an early
"hacked" version of exception handling???)

                        Good luck,

                                David Pannett (dpannett@wellesley.edu)

Whoops... I see that I may have added to the confusion with my last post
on this subject :-( .  I wrote:

1) the destructors for x and y above are indeed called when the exception
   is thrown, and

2) the code executed on return from the thrown exception is *not* "the code
   that was about to be executed before the throw occured".  Execution will
   resume at the point *following* the original *call* to f(...), not in the
   middle of f(...) .

Mea culpa, since the original code example didn't actually include the call
to f(...); vapor lock on my part.  Point 2) above assumes code resembling

try
{
  f(...);  // throws exception
}
catch(...)
{

  // handle exception

}
// execution resumes here following thrown exception
..

(which I suspect most readers of this newsgroup know already -- my concern
was for the terribly misleading answers that the original poster received,
to which I seem to have hastily added :-(  .)

                                Hope this helps ,

                                David Pannett (dpannett@wellesley.edu)