Srinivas Vobilisetti <Srinivas.Vobilisetti@mci.com> wrote:
> As long as the program terminates gracefully (return from main() or
> using exit()), the objects both global and local will be destroyed in
> the reserve order in which they were created.

Local objects will not be destroyed by a call to exit(). They will
only be destroyed by exiting the scope that they were created in,
e.g.  through a return.

Paul
---
[ 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
]

Monette Stephens wrote:
>
> Is there anything in the C++ language spec which says thatdestructors
> are called in the order in which they were created when an object goes
> out of scope?

C++ guarantee that the objects' destructor will be called in the REVERSE
order in which the objects' constructors were called when the object
goes out of scope. Remember, it is responsiblity of the programmer to
destroy objects created explicitly ( i.e. using new operator).

> So, if a program terminates, can one rely on the order in which
> thedestructors are called?  I'm not asking whether it's implemented
> thatway by the compiler, but whether it's a feature of the language.

As long as the program terminates gracefully (return from main() or
using exit()), the objects both global and local will be destroyed in
the reserve order in which they were created.

Srinivas

> Please email responses - the news server I go through is down for the
> next week or so.
>
> Thanks,
>
---
[ 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
]

Is there anything in the C++ language spec which says thatdestructors
are called in the order in which they were created when an object goes
out of scope?

So, if a program terminates, can one rely on the order in which
thedestructors are called?  I'm not asking whether it's implemented
thatway by the compiler, but whether it's a feature of the language.

Please email responses - the news server I go through is down for the
next week or so.

Thanks,

M.
---
[ 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
]

Monette Stephens <ms@acc.com> wrote in article
<33D69202.49AA59EC@acc.com>...
> Is there anything in the C++ language spec which says thatdestructors
> are called in the order in which they were created when an object goes
> out of scope?

Variables allocated on the stack are destructed in reverse order of
construction (if they get destructed at all, for instance a call to exit()
does not destruct auto variables).  I believe most current implementations
get this right.

Static variables are destructed at program exit (exit(), return from main)
in reverse order of completion of construction (interlaced with reversed
atexit() handlers).  Many implementations get this wrong for local static
objects (I believe cfront got this wrong).

Subobjects (within a larger struct or array) are also destructed in reverse
order of construction.  (I'm not sure the standard requires this for
arrays).

Objects on the heap are destructed when you explicitly tell them to be
destructed (implementations are probably allowed to do "garbage collection
destruction" but that is not common).

In general objects are destructed in reverse order of construction and the
only tricks involved occur if the objects have different storage classes or
if their construction overlapped in time.

Some forms of program termination (abort()) prevent any further destruction.
---
[ 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
]

In article <01bc992c$b1a40b20$2864370a@janeway>,
Bill Wade <bill.wade@stoner.com> wrote:
>Static variables are destructed at program exit (exit(), return from main)
>in reverse order of completion of construction (interlaced with reversed
>atexit() handlers).  Many implementations get this wrong for local static
>objects (I believe cfront got this wrong).

The requirement to use atexit() handlers for destructing static vars
seems to tie the language into a particular execution paradym. How
can atexit() handlers handle the case of dynamically loaded/unloaded
code that is not tied to task entry/exit? We have an embedded system
that does just that. It is similar to the dlopen/dlclose in Solaris
which brings a shared module into a process's address space and
removes it from the process's address space. If the shared object
contained any static vars (say a function scoped static object) then
the destructor for that object will get linked into the task's
exit chain but... the code/data space for the object may not be
present when the task actually exits (and the destructor for the
object wasn't called before the code/data was unloaded).

--
Gary Mussar <mussar@nortel.ca> | Phone: (613) 763-4937
Nortel                         | FAX:   (613) 763-2626
---
[ 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                             ]