Paul D. DeRocco <pderocco@ix.netcom.crud.com> writes:

> Bill Wade wrote:
> >
> >   3) I'm not sure the rules are clear on the following.  If a destructor
> > throws an exception, will other sub-objects in the larger object have their
> > destructors called?  For instance
> >   class FooFoo{ Foo a; Foo b; };
> > If the body of ~FooFoo has been completed and the implicit b.~Foo() throws
> > an exception does a.~Foo() get called?  What if I change a,b to an array of
> > two elements?

Sub-objects are destructed in reverse order of ... you know the end,
everybody heard it 100 times (at least). The rules are very clear (but
they were a little bit obscure before the London meeting).

> I'm not sure the draft standard spells it out, but it's hard to imagine
> how one would compile the code so that a.~Foo() would get called.

Since several months (the discutions about exceptions in dtors),
I'm wondering what problem doing a stack walkback in a dtor causes
(compared to other functions).

> At
> that point, an exception is in the process of being thrown, so what
> would happen if a.~Foo() also threw an exception? I'll bet every
> existing compiler just gives up and lets the first exception propagate
> out of ~FooFoo.

Then it isn't conforming.

> It is for reasons like this that I pretend that it is illegal for
> destructors to throw exceptions. A real can of worms.

It's perfectly legal as long has the dtor isn't called because of
a stack walkback, and the exception is caught before exiting such
a dtor.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Mark H. Zellers <mzellers@infomediate.com> wrote in article
<5sr5d9$4ec$1@usenet88.supernews.com>...
> Assume the classes Foo and Bar both have creator and destructor methods
>
>         {
>                 Foo foo;
>                 Bar bar(&foo);
>
>                 ....
>         }
>
> Is there any guarantee that foo will be destroyed after bar?  I.E. must
> destruction of automatic variables always happen in reverse order of
creation?

Under normal circumstances auto objects will be destructed in reverse order
of completion of construction.  Abnormal circumstances include:
  1) Destruction never occurs (terminate() or exit()).
  2) Explicit calls to destructors (foo.~Foo()), however the implicit call
will still occur at the expected place.
  3) I'm not sure the rules are clear on the following.  If a destructor
throws an exception, will other sub-objects in the larger object have their
destructors called?  For instance
  class FooFoo{ Foo a; Foo b; };
If the body of ~FooFoo has been completed and the implicit b.~Foo() throws
an exception does a.~Foo() get called?  What if I change a,b to an array of
two elements?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Assume the classes Foo and Bar both have creator and destructor methods

        {
                Foo foo;
                Bar bar(&foo);

                ....
        }

Is there any guarantee that foo will be destroyed after bar?  I.E. must
destruction of automatic variables always happen in reverse order of creation?

Thanks,

Mark Z.





-------------------------------------------------------------------------------
Mark H. Zellers                                        mzellers@InfoMediate.Com
InfoMediate, Inc.                                           Ph:  (650) 327-9893
445 Sherman Ave, Palo Alto, CA                              Fax: (650) 327-6575
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5sr5d9$4ec$1@usenet88.supernews.com> on 13 Aug 97 05:07:31
GMT, mzellers@infomediate.com says...
> Assume the classes Foo and Bar both have creator and destructor methods
>
>         {
>                 Foo foo;
>                 Bar bar(&foo);
>
>                 ....
>         }
>
> Is there any guarantee that foo will be destroyed after bar?  I.E. must
> destruction of automatic variables always happen in reverse order of creation?
Yes - section 6.6 para 2:

"On exit from a scope (however accomplished), destructors (12.4) are
called for all constructed objects with automatic storage duration
(3.7.2) (named objects or temporaries) that are declared in that
scope, in the reverse order of their declaration."

--
Jim Hyslop O-

Urban Legend or true story? #1:
Police in Wichita, Kansas, arrested a 22-year-old man at an airport
hotel after he tried to pass two (counterfeit) $16 bills.

Don't pass on that email about someone dying of cancer or a "new
super-powerful computer virus" until you check out the Internet Hoax
page http://ciac.llnl.gov/ciac/CIACHoaxes.html first!
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Mark H. Zellers wrote:
>
> Assume the classes Foo and Bar both have creator and destructor methods
>
>         {
>                 Foo foo;
>                 Bar bar(&foo);
>         }
>
> Is there any guarantee that foo will be destroyed after bar?  I.E. must
> destruction of automatic variables always happen in reverse order of creation?

Yes. Section 6.6 "Jump statements" says:

   "On exit from a scope (however accomplished), destructors are
   called for all constructed objects with automatic storage duration
   (named objects or temporaries) that are declared in that scope,
   in the reverse order of their declaration."

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bill Wade wrote:
>
>   3) I'm not sure the rules are clear on the following.  If a destructor
> throws an exception, will other sub-objects in the larger object have their
> destructors called?  For instance
>   class FooFoo{ Foo a; Foo b; };
> If the body of ~FooFoo has been completed and the implicit b.~Foo() throws
> an exception does a.~Foo() get called?  What if I change a,b to an array of
> two elements?

I'm not sure the draft standard spells it out, but it's hard to imagine
how one would compile the code so that a.~Foo() would get called. At
that point, an exception is in the process of being thrown, so what
would happen if a.~Foo() also threw an exception? I'll bet every
existing compiler just gives up and lets the first exception propagate
out of ~FooFoo.

It is for reasons like this that I pretend that it is illegal for
destructors to throw exceptions. A real can of worms.

--

Ciao,
Paul

(Please remove the extra "crud" from the return address,
which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]