When two or more auto objects go out of scope at the same time, is there any official rule over the order in which the destructors are called?

According to the experiments I've done so far (DMD 0.79, Windows 98SE), they seem to be always destructed in the reverse order that they were declared, whether they were declared at the same level or not.  This is indeed the sensible thing to do, since the second object could require the first to be valid throughout its lifetime.

But is this guaranteed?  The spec doesn't seem to address the issue.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> When two or more auto objects go out of scope at the same time, is there any official rule over the order in which the destructors are called?
> 
> According to the experiments I've done so far (DMD 0.79, Windows 98SE), they seem to be always destructed in the reverse order that they were declared, whether they were declared at the same level or not.  This is indeed the sensible thing to do, since the second object could require the first to be valid throughout its lifetime.
> 
> But is this guaranteed?  The spec doesn't seem to address the issue.

If the spec does not mention this then it should be updated.  C and C++ gurantee that destruction is in reverse order from declaration, and I would be shocked if D weren't the same way, as unpredictable destruction order would wreak havoc with app writing.


Sean

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
news:c2knb9$2ihl$1@digitaldaemon.com
| When two or more auto objects go out of scope at the same
| time, is there any official rule over the order in which
| the destructors are called?
|
| According to the experiments I've done so far (DMD 0.79,
| Windows 98SE), they seem to be always destructed in the
| reverse order that they were declared, whether they were
| declared at the same level or not.  This is indeed the
| sensible thing to do, since the second object could
| require the first to be valid throughout its lifetime.
|
| But is this guaranteed?  The spec doesn't seem to address
| the issue.
|
| Stewart.

IIRC, Walter once said that was true.

-----------------------
Carlos Santander Bernal