In clause =A75.2.2/8 we read: "The order of evaluation of arguments is
unspecified. All side effects of argument expression evaluations take
effect before the function is entered. The order of evaluation of the
postfix expression and the argument expression list is unspecified."

When I originally encountered that fact, it didn't have much impact on me=
.=20
It seemed to simply mean that I shouldn't things I had no intention of ev=
er
doing. There seemed to be some value in leaving this ordering open for th=
e
compiler to chose the most efficient sequence. Then I encountered this
article: http://www.gotw.ca/gotw/056.htm

"2. In your travels through the dusty corners of your company's code
archives, you find the following code fragment:

    //  Example 2
    //

    //  In some header file:
    void f( T1*, T2* );

    //  In some implementation file:
    f( new T1, new T2 );

Does this code have any potential exception safety problems? Explain.

Yes, there are several potential exception safety problems.

Brief recap: An expression like "new T1" is called, simply enough, a
new-expression. Recall what a new-expression really does (I'll ignore
placement and array forms for simplicity, since they're not very relevant
here):

    - it allocates memory

    - it constructs a new object in that memory

        - if the construction fails because of an exception the allocated
memory is freed

So each new-expression is essentially a series of two function calls: one
call to operator new() (either the global one, or one provided by the typ=
e
of the object being created), and then a call to the constructor.

For Example 1, consider what happens if the compiler decides to generate
code as follows:

1: allocate memory for T1
2: construct T1
3: allocate memory for T2
4: construct T2
5: call f()

The problem is this: If either step 3 or step 4 fails because of an
exception, the C++ standard does not require that the T1 object be
destroyed and its memory deallocated. This is a classic memory leak, and
clearly not a Good Thing."

Do compilers really take advantage of this flexibility?  How much does it
buy?  Has the theoretical problem actually manifested itself in productio=
n
code?  Would specifying order on the evaluation of function arguments
impose great hardship on implementers?  Would it adversely impact executi=
on
speed, compile time, or code size?  How much?
--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]