2

I was reading "Bjarne Stroustrup's C++ Style and Technique" FAQ where he mentioned about this FAQ What's the value of i++ + i++?

In this he has mentioned "...the order of evaluation of function arguments are undefined." when he is refering to f(v[i],i++); example.

I am aware of that the order of evaluation of function arguments is unspecified not undefined but in this case is it undefined because we are relying on value of i so as to which v[i] to pass or its an error in the FAQ itself?

cyber_raj
  • 1,780
  • 1
  • 14
  • 25
  • I honestly believe the only people who need to care about the distinction between *unspecified* and *undefined* are C++ compiler writers... –  Jan 23 '11 at 07:46
  • @David What it has to do with how to use SO, i am here to gain knowledge not concerned with rate, badges and no. of votes...r u gonna take all this with u when u'll die. – cyber_raj Jan 23 '11 at 09:17
  • If you play along with the system here you might find people more willing to help and so be able to gain more knowledge. That's my point. – David Heffernan Jan 23 '11 at 09:26

2 Answers2

4

The order of evaluation of function arguments is unspecified but the behaviour of the expression is undefined. Bjarne has just got it wrong. :-)

Check out this thread to understand the difference between Unspecified Behaviour and Undefined Behaviour.

I once asked Bjarne the difference between unspecified and undefined and this was his reply..

Personally, I don't bother with the distinction between "undefined" and "unspecified"; do you know what it is? That code should be taken out and shot in either case: (carefully avoiding the words "undefined" and "unspecified")

.....

You don't need to know: just avoid both. If someone really want to know they can look up the definitions in the C++ or C standards (my bet would be that the C and C++ standards will disagree on unimportant details).

Community
  • 1
  • 1
Prasoon Saurav
  • 91,295
  • 49
  • 239
  • 345
0

I think we are lost in semantics here. Specification is definition, directly or by omission. Much of unspecified behavior was left to allow optimization through implementation-defined behavior, what leads to undefined behavior, at least if you move your code to different compilers or hardware, so your code loses generality, and it also has probably lost clarity and simplicity. Like Brian Kernighan also says, code which try to take advantage of potential "side effect" artifices is often not good style. But it was funny see somebody pointing Bjarne Stroustrup "mistakes". :)

Aureliano Buendia
  • 615
  • 5
  • 10