On Jul 23, 8:36 pm, JoshuaMaur...@[EMAIL PROTECTED]
wrote:
> On Jul 22, 2:58 pm, Le Chaud Lapin <jaibudu...@[EMAIL PROTECTED]
> wrote:
> #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()); }
> The order of argument evaluation, i.e. whether foo or bar is called
> first, is left unspecified. An implementation is free to choose either
> order, and it does not have to be internally consistent. It could
> "flip a coin" at every compile to pick an order. The reason for this,
> and basically the lack of specified order in all similar subexpression
> evaluation, is for efficiency. If you allow the compiler to pick
> either order, it's possible that the compiler can generate better
> code.
I think this example would not be applicable because it presumes that
one might infer that which has already been preempted by specification
- that there is no order. In the example I gave, where one statement
follows the other, it is understood that one statement completes
before the other.
You wrote:
> 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.
Why? On what basis are you allowed to claim, "it is generally the
case"? :)
It is your intuition, gained from a combination of experience and raw
insight. We are essentially saying the same thing:
I wrote:
> 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.
> Shortly thereafter, even a vague understanding of the mechanisms of
> memory allocation on stack and heap would give preference to 2.
You wrote:
> Add exceptions to
> the mix, and this order of destruction is required for writing
> sensible code.
I wrote:
> As often happens, once one has used #2 in practice for years, s/he
> will have discovered an enumerable number of situations where the more
> "beautiful" choice, #2, was not just a matter of aesthetics, but
> necessity.
So in this case, the necessity stems from exceptions.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
