Question: In C and C++, is there a fixed order for evaluation of parameter to the function? I mean, what do the standards say? Is it `left-to-right` or `right-to-left`?
I am getting confusing information from the books.

Is it necessary that `function call` should be implemented using `stack only`? What do the C and C++ standards say about this?

Answer: 
C and C++ are two completely different languages; don't assume the same rules always apply to both. In the case of parameter evaluation order, however:

C99:

> 
> **6.5.2.2 Function calls**  
> 
> ...  
> 
> 10 The order of evaluation of the function designator, the actual arguments, and
>  subexpressions within the actual arguments is unspecified, but there is a sequence point
>  before the actual call.
> 

[*Edit*]
C11 (draft):

> 
> **6.5.2.2 Function calls**  
> 
> ...  
> 
> 10 There is a sequence point after the evaluations of the function designator and the actual
> arguments but before the actual call. 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.94)  
> 
> ...  
> 
> 94) In other words, function executions do not ‘‘interleave’’ with each other.
> 

C++:

> 
> **5.2.2 Function call**  
> 
> ...  
> 
> 8 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.
> 

Neither standard mandates the use of the hardware stack for passing function parameters; that's an implementation detail. The C++ standard uses the term "unwinding the stack" to describe calling destructors for automatically created objects on the path from a `try` block to a *throw-expression*, but that's it. Most popular architectures *do* pass parameters via a hardware stack, but it's not universal. 

[*Edit*]

> 
> I am getting confusing information from the books.
> 
> 
> 

This is not in the least surprising, since easily 90% of books written about C are simply *crap*. 

While the language standard isn't a great resource for *learning* either C or C++, it's good to have handy for questions like this. The official™ standards documents cost real money, but there are drafts that are freely available online, and should be good enough for most purposes.

The latest C99 draft (with updates since original publication) is available [here](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf). The latest pre-publication C11 draft (which was officially ratified last year) is available [here](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf). And a publicly availble draft of the C++ language is available [here](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf), although it has an explicit disclaimer that some of the information is incomplete or incorrect.
As far as I know, the function `printf` has an exception here.

For an ordinary function `foo`, the order of evaluation of `foo(bar(x++), baz(++x))` is undefined. Correct! However `printf`, being an ellipsis function has a somewhat more definite order of evaluation.

The `printf` in the standard library, in fact, has no information about the number of arguments that has been sent to. It just tries to figure out the number of variables from the string placeholders; namely, from the number of percent operators (`%`) in the string. The C compiler starts pushing arguments from the very right towards left; and the address of the string is passed as a last argument. Having no exact information about the number of arguments, `printf` evaluates the last address (the string) and starts replacing the `%`'s (from left to right) with values of the corresponding addresses in the stack. That is, for a `printf` like below;

```
{
    int x = 0;
    printf("%d %d %f\n", foo(x), bar(x++), baz(++x));
}

```

The order of evaluation is:

1. x is incremented by 1,
2. function baz is called with `x = 1`; return value is pushed to the stack,
3. function bar is called with `x = 1`; return value is pushed to the stack,
4. x is incremented by 1,
5. function foo is called with `x = 2`; return value is pushed to the stack,
6. the string address is pushed to the stack.

Now, `printf` has no information about the number of arguments that has been sent to. Moreover, if `-Wall` is not issued in compilation, the compiler will not even complain about the inconsistent number of arguments. That is; the string may contain 3 `%`'s but the number of arguments in the `printf` line can be 1, 2, 3, 4, 5 or even can contain just the string itself without any arguments at all.

Say, the string has 3 placeholders and you've send 5 arguments (`printf("%d %f %s\n", k1, k2, k3, k4, k5)`). If compilation warning is turned off, the compiler will not complain about excessive number of arguments (or insufficient number of placeholders). Knowing the stack address, `printf` will;

1. treat the first integer width in the stack and print it as an integer (without knowing whether it is an integer or not),
2. treat the next double width in the stack and print it as a double (without knowing whether it is a double or not),
3. treat the next pointer width in the stack as a string address and will try to print the string at that address, until it finds a string terminator (provided, the address pointed to belong to that process; otherwise raises segmentation error).
4. and ignore the remaining arguments.