--- In [email protected], Arvind Balodia <arvind.balo...@...> wrote: > > As i saw the simple problem of increment and decrement > has become an issue of debate in this group and now we > are started to blame on each others knowledge.
There really isn't anything being debated. There is only ignorance being corrected. Of course, we are all here to correct our ignorance. ;) > ...Consider the following statement: > x = j * j++; > > The C language does not specify which multiplication > operand is to be evaluated first. <snip> True, but more importantly, it leaves undefined the behaviour of an expression where an object value is used for a purpose other than computing the new value of the that object. In this case, the left j is a reading the value of j that is not used to compute the new value in j++. The standard does impose a meaning to the statement. Undefined behaviour doesn't always mean the code will not have a precise meaning on any given implementation. Undefined behaviour is a licence for implementations to build extensions if they so choose. However, for this particular example, NO COMPILER that I know of will attach or guarantee a meaning to that statement! Even if one compiler seems to operate in a deterministic way for these sorts of expressions, that is no reason to assume that it will always do so, let alone that others must be similar. > The side effect problem also crops up in function calls > because the C language does not guarantee the order in > which arguments are evaluated. For example, the function > call f(a, a++) is not portable because compilers are free > to evaluate the arguments in any order they choose. No, the unspecified order of evaluation is incidental! Unspecified order of evaluation does not mean code is not portable. Consider... y = cos(theta) * sin(theta); z = f(x) + log(y); The order of function calls is unspecified, but the code is still portable. -- Peter
