This is to elaborate on the order of evaluation issue.
Here's what the C++11 standard says about order of evaluation:
- Every value computation and side effect associated with a full-expression is sequenced before every value computation and side effect associated with the next full-expression to be evaluated. (§1.9 [intro.execution]/p15)
- The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. (§1.9 [intro.execution]/p15)
- Evaluations of operands of individual operators and of subexpressions of individual
expressions are unsequenced. (§1.9 [intro.execution]/p15)
- When calling a function (whether or not the function is inline), every value computation and side effect associated with any argument expression, or with the postfix expression designating the called function, is sequenced before execution of every expression or statement in the body of the called function. (§1.9 [intro.execution]/p16)
- Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function. (§1.9 [intro.execution]/p16)
If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. (§1.9 [intro.execution]/p15)
Now we can apply these rules to this expression: _suma + sumaRec(--_suma).
- The evaluations of the two operands of the +operator is unsequenced. The compiler is free to evaluate_sumafirst, thensumaRec(--_suma), or the reverse.
- The value computation and side effects of --_sumais sequenced before the call tosumaRec.
- Everything is indeterminately sequenced with respect to the sumaReccall itself; i.e., the compiler could evaluate_sumaeither before or after the execution of the statements in thesumaRecfunction, but not during it.
- The value computations, but not the side effect, of the two operands of +are sequenced before computation of the result of the+operator.
In particular, because the side effect (storing the decremented value) on a scalar object (_suma) is unsequenced with respect to a value computation using the value of the same scalar object (computation of the value of the first operand of +), the behavior is undefined.
A conforming compiler can do any of the following:
- evaluate _sumafirst,--_sumasecond,sumaRecthird
- evaluate --_sumafirst,sumaRecsecond,_sumathird
- evaluate --_sumafirst,_sumasecond, andsumaRecthird
- perform the value computation of --_sumafirst, the value computation of_sumasecond, the side effect of--_suma(storing the decremented value) third, andsumaRecfourth
- conjure nasal demons, chomp up your hard drive, or anything else it wants to do. When the behavior is undefined, all bets are off.
It is worth emphasizing that operator precedence and order of evaluation are entirely different things. Operator precedence means that an expression like f() + g() * h() is interpreted by the compiler as f() + (g() * h()) and not (f() + g()) * h(), but there is no guarantee whatsoever that f(), g(), and h() will be evaluated in any particular order. In fact, if this expression appears twice in the same code, the compiler is not even required to be consistent: the evaluation order can be f(), g(), h() in one and g(), f(), h() in another.
Edit: To note that GCC, as expected, emits a warning for this code: 
g++ -march=native -std=c++11 -Wall -Wextra -pedantic main.cpp && ./a.out
main.cpp: In function 'int sumaRec(int)':
main.cpp:9:39: warning: operation on '_suma' may be undefined [-Wsequence-point]
         return _suma + sumaRec(--_suma);
                                       ^
It's always a good idea to compile with full warnings enabled.