void f(shared_ptr<int>, int);
int g();
void ok()
{
shared_ptr<int> p(new int(2));
f(p, g());
}
void bad()
{
f(shared_ptr<int>(new int(2)), g());
}
auto_ptr<TraceHeap> pMyObject(new TraceHeap(5),2); //I added the second argument for the sake of discussion (1)
Quote:ISO/IEC 14882:2003(E), Chapter 8: Declarators.
9. [...]The order of evaluation of function arguments is unspecified[...]
int a = foo(), bar(); foo(foo(), bar())Quote:When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body.
void foo (int, int) { cout << "foo!\n"; } int main () { foo (frob(), y=3); }Quote:There is also a sequence point after the copying of a returned value and before the execution
of any expressions outside the function11). Several contexts in C + + cause evaluation of a function
call, even though no corresponding function call syntax appears in the translation unit. [Example: evaluation
of a new expression invokes one or more allocation and constructor functions; see 5.3.4. For another
example, invocation of a conversion function (12.3.2) can arise in contexts in which no function call syntax
appears. ] The sequence points at function-entry and function-exit (as described above) are features of the
function calls as evaluated, whatever the syntax of the expression that calls the function might be.
Quote:Original post by setiz1
Now if and only if allocation of TraceHeap(5) fails (and subsequent exception raised), wouldn't that imply that the second argument "2" is never called?
Quote:Original post by DevFredQuote:Original post by setiz1
Now if and only if allocation of TraceHeap(5) fails (and subsequent exception raised), wouldn't that imply that the second argument "2" is never called?
I don't see your point. It does not matter if "2" is evaluated first, last or inbetween, because it doesn't have any side effects. Can you elaborate?
struct Foo{ Foo(const int&) { throw 0; }};void f(int* x, Foo y);void g(int* x, int y);int main(){ f(new int(2), 2); g(new int(2), 2);}
auto_ptr<TraceHeap> pMyObject(new TraceHeap(5),2);Quote:
Before a function is entered in a function call. The order in which the arguments are evaluated is not specified, but this sequence point means that all of their side effects are complete before the function is entered. In the expression f(i++) + g(j++) + h(k++), f is called with a parameter of the original value of i, but i is incremented before entering the body of f. Similarly, j and k are updated before entering g and h respectively. However, it is not specified in which order f(), g(), h() are executed, nor in which order i, j, k are incremented. The values of j and k in the body of f are therefore undefined.[3] Note that a function call f(a,b,c) is not a use of the comma operator and the order of evaluation for a, b, and c is unspecified.
Quote:Original post by setiz1
such a restriction.
Quote:Original post by Sc4FreakQuote:Original post by DevFredQuote:Original post by setiz1
Now if and only if allocation of TraceHeap(5) fails (and subsequent exception raised), wouldn't that imply that the second argument "2" is never called?
I don't see your point. It does not matter if "2" is evaluated first, last or inbetween, because it doesn't have any side effects. Can you elaborate?
Consider:struct Foo{ Foo(const int&) { throw 0; }};void f(int* x, Foo y);void g(int* x, int y);int main(){ f(new int(2), 2); g(new int(2), 2);}
Now what happens when you call f and the first parameter is evaluated first?
struct Foo{ Foo(const int&) { throw 0; } int a;};void f(int* x, Foo y){ std::cout << y.a << std::endl;}//void g(Foo* x, int y){}int main(){ f(new int(2), 2); // 2 != typeof(Foo)!! Happily compiles+links on MSVC and halts. //g(new Foo(2), 2);}Quote:Original post by setiz1
if allocation of new TraceHeap(5) fails, passing the value "2" to a function will fail right?
Quote:Original post by setiz1
if "2" isn't called first [...] and if exception is raised while dynamically allocating the first argument [...] then what is the expected outcome?
