Re: Order of destruct of local variables

JoshuaMaurice@[EMAIL PROTECTED]
 ha scritto:
> On Jul 22, 2:58 pm, Le Chaud Lapin <jaibudu...@[EMAIL PROTECTED]
> wrote:
>> Suppose instead that you were the language designer, and someone asked
>> you to test your intuition to determine the proper order of
>> destruction.  Your choices are:
>>
>> 1. FIFO (born first die first)
>> 2. LIFO (born first die last)
>> 3. Whatever
>>
>> I contend that a good engineering mindset in the context of
>> computation should immediately eliminate #3 from consideration. Since
>> we are talking about construction/deconstruction, we should intuitvely
>> known that #1 or #2 is the correct answer, *without* experimentation.

Well, programmers versed in garbage collected languages might disagree.
In such languages, not only objects are not necessarily destroyed when
their variables exit from scope, but the order of destruction is
unspecified unless there is a dependency between the objects themselves.

> Actually, no. This reasoning does not hold in all cases. I just had a
> rather long argument with a Java friend of mine over whether this
> should always be the case. It is in Java. C++ is more lax than your a
> priori reasoning would show. For example, the following program has
> unspecified, but not undefined, behavior:
> 
> #include <iostream>
> int foo() { std::cout << "foo" << std::endl; return 0; }
> int bar() { std::cout << "bar" << std::endl; return 0; }
> void baz(int , int ) {}
> int main() { baz(foo(), bar()); }

This example is a totally different issue and so it can't be used as an
argument against what Le Chaud Lapin said. An expression used a function
argument cannot refer to another expression used as another function
argument. Tem****aries are not like variables. The construction of a
variable can refer to any other variable in scope and so it must be
allowed to rely on the fact that the lifetime of such variable is
already started and is not ending too soon.

> Also, to get back to the first point of this thread. The big reason
> why the order of destruction of local objects is defined this way is
> RAII. One acquires resources in constructors, and then one releases
> them in destructors. It's generally the case you want to release
> resources in the opposite order you acquired them. Add exceptions to
> the mix, and this order of destruction is required for writing
> sensible code.
> 

The order of destruction is common sense, it's not there because of
RAII, although it's an essential ingredient of the RAII recipe. The key
point in RAII is the guarantee that destructors are called as soon as
the variable exits from scope and that's why RAII is not a good idiom in
garbage collected languages.

Just my opinion,

Ganesh

-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]