f(v[i],i++); is Undefined or Unspecified?

[avsharath]

In "Bjarne Stroustrup's C++ Style and Technique FAQ" at:
http://www.research.att.com/~bs/bs_f...aluation-order

for the statement:
f(v[i],i++);

he says that "the result is undefined because the order of evaluation
of function arguments are undefined".

But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

I think it is undefined because the value of 'i' is accessed and also
moidified within the sequence point and hence it is undefined.

Sharath A.V

[James Bannon]

av*******@gmail.com wrote:

In "Bjarne Stroustrup's C++ Style and Technique FAQ" at:
http://www.research.att.com/~bs/bs_f...aluation-order

for the statement:
f(v[i],i++);

he says that "the result is undefined because the order of evaluation
of function arguments are undefined".

But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

I think it is undefined because the value of 'i' is accessed and also
moidified within the sequence point and hence it is undefined.

Sharath A.V

According to the standard the value of f is unspecified but what does
that mean in practice? Undefined results because we cannot guarantee
what the result of calling f will be. I think we can allow the inventor
of the language a little leeway in describing the effects of an error.
Besides if every FAQ or textbook used the language of the standard
without explanation they would be virtually unreadable.

Cheers
Jim.

[Pete Becker]

James Bannon wrote:

>>

According to the standard the value of f is unspecified but what does
that mean in practice? Undefined results because we cannot guarantee
what the result of calling f will be.

Well, in a way, yes, but this is sloppy wording. The standard gives the
term "undefined behavior" a specific meaning. Using that term to mean
something different is simply confusing. So, please, when you're talking
about the language definition, use the term "undefined behavior" to mean
behavior of an erroneous program for which the standard imposes no
requirements. Use the term "unspecified behavior" to mean behavior of a
well-formed program that depends on the implementation (usually there is
an obvious set of alternatives).

[Salt_Peter]

av*******@gmail.com wrote:

In "Bjarne Stroustrup's C++ Style and Technique FAQ" at:
http://www.research.att.com/~bs/bs_f...aluation-order

for the statement:
f(v[i],i++);

he says that "the result is undefined because the order of evaluation
of function arguments are undefined".

But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

I think it is undefined because the value of 'i' is accessed and also
moidified within the sequence point and hence it is undefined.

Sharath A.V

Both he and the standard are saying the same thing.
How can you modify and access a variable simultaneously? Thats
impossible.
You've missunderstood both statements.
What he and the standard are saying is that no restriction is imposed
on the compiler to first evaluate one argument and then the other in
any particular sequence.
Undefined or unspecified: same thing.

I disagree with your intepretation as well.
v[i] is a particular element in a container, the question is which one?
The answer is "it doesn't matter", unspecified, undefined, "who cares",
not guarenteed, etc.

[James Bannon]

Pete Becker wrote:

James Bannon wrote:

>>>

According to the standard the value of f is unspecified but what does
that mean in practice? Undefined results because we cannot guarantee
what the result of calling f will be.

Well, in a way, yes, but this is sloppy wording. The standard gives the
term "undefined behavior" a specific meaning. Using that term to mean
something different is simply confusing. So, please, when you're talking
about the language definition, use the term "undefined behavior" to mean
behavior of an erroneous program for which the standard imposes no
requirements. Use the term "unspecified behavior" to mean behavior of a
well-formed program that depends on the implementation (usually there is
an obvious set of alternatives).

Normally I would quote directly from the Standard as I have a copy on my
bookshelf, that is when I want to be sure I'm not putting in my own
(probably mistaken) interpretation of some clause. However, I think you
have to remember that the audience reading the pages of an FAQ are not
likely to be language specialists and are unlikely to appreciate the
difference between "undefined" and "unspecified" especially since both
usually arise from the use of erroneous constructs and both have similar
effects in the sense that "results cannot be relied upon". If you were
teaching a class of learners would you say "the results are unspecified"
or "don't do this because, even though the language allows it, it
doesn't work".

Cheers
Jim.

[Jack Klein]

On 16 Jul 2006 08:30:56 -0700, av*******@gmail.com wrote in
comp.lang.c++:

In "Bjarne Stroustrup's C++ Style and Technique FAQ" at:
http://www.research.att.com/~bs/bs_f...aluation-order

for the statement:
f(v[i],i++);

he says that "the result is undefined because the order of evaluation
of function arguments are undefined".

Bjarne's wording is less than accurate here. Actually, the order of
evaluation of function arguments is unspecified.

But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

But the first point in his statement, that the result is undefined, is
true. Regardless of the order of evaluation of the function
arguments, 'i' is both modified, and its value read other than for the
purpose of deriving the new value.

I think it is undefined because the value of 'i' is accessed and also
moidified within the sequence point and hence it is undefined.

Sharath A.V

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Julián Albo]

James Bannon wrote:

According to the standard the value of f is unspecified but what does
that mean in practice?

It means: "Boys, don't try this at home!"

--
Salu2

[Pete Becker]

James Bannon wrote:

Pete Becker wrote:

>James Bannon wrote:

>>>>
According to the standard the value of f is unspecified but what does
that mean in practice? Undefined results because we cannot guarantee
what the result of calling f will be.

Well, in a way, yes, but this is sloppy wording. The standard gives
the term "undefined behavior" a specific meaning. Using that term to
mean something different is simply confusing. So, please, when you're
talking about the language definition, use the term "undefined
behavior" to mean behavior of an erroneous program for which the
standard imposes no requirements. Use the term "unspecified behavior"
to mean behavior of a well-formed program that depends on the
implementation (usually there is an obvious set of alternatives).

Normally I would quote directly from the Standard as I have a copy on my
bookshelf, that is when I want to be sure I'm not putting in my own
(probably mistaken) interpretation of some clause.

The words I used are a paraphrase of the words in the standard.

However, I think you
have to remember that the audience reading the pages of an FAQ are not
likely to be language specialists and are unlikely to appreciate the
difference between "undefined" and "unspecified" especially since both
usually arise from the use of erroneous constructs and both have similar
effects in the sense that "results cannot be relied upon". If you were
teaching a class of learners would you say "the results are unspecified"
or "don't do this because, even though the language allows it, it
doesn't work".

I have no problem with someone saying "the results cannot be relied
upon." What I objected to was the switch from technical language
(undefined behavior versus unspecified behavior in the original message)
to non-technical language using some of the same words.

[James Bannon]

Julián Albo wrote:

James Bannon wrote:

>According to the standard the value of f is unspecified but what does
that mean in practice?

It means: "Boys, don't try this at home!"

Precisely, and undefined behaviour means precisely the same thing from
this point-of-view: don't do it; it doesn't work; career-limiting move;
abuse of the language; bug; or however you want to put it.

Of course, if we're speaking "standardese" we should be precise because
there is a difference between undefined and unspecified just as there is
a difference between mandated and implementation-defined (IMHO the
latter distinction is more important).

Cheers
Jim

[Kaz Kylheku]

av*******@gmail.com wrote:

But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

No, because he didn't write that the /behavior/ is undefined, but that
the /order/ is undefined.

This is accurate because it's what unspecified behavior means with
respect to order: the standard does not define the order, nor require
that the implementation document how the order is chosen.

The informal language Stroustrup is using is perfectly adequate for the
purpose of the FAQ.

The reader is already suposed to understand that combining v[i] and i++
in the same expression causes undefined behavior. WIth that additional
example, Stroustrup is illustrating that the undefined behavior cannot
be prevented by separating pieces of the expression into separate
argument expressions, because the order of evaluation of arguments is
not defined either.

[James Bannon]

Kaz Kylheku wrote:

av*******@gmail.com wrote:

>But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

No, because he didn't write that the /behavior/ is undefined, but that
the /order/ is undefined.

This is accurate because it's what unspecified behavior means with
respect to order: the standard does not define the order, nor require
that the implementation document how the order is chosen.

The informal language Stroustrup is using is perfectly adequate for the
purpose of the FAQ.

The reader is already suposed to understand that combining v[i] and i++
in the same expression causes undefined behavior. WIth that additional
example, Stroustrup is illustrating that the undefined behavior cannot
be prevented by separating pieces of the expression into separate
argument expressions, because the order of evaluation of arguments is
not defined either.

An auxillary question (just to clarify for my own benefit). I presume
that f(v[i++]) is defined (providing i lies in the interval [v.begin(),
v.end() - 1]?

Thanks,
Jim.

[Julián Albo]

James Bannon wrote:

>>According to the standard the value of f is unspecified but what does
that mean in practice?

>It means: "Boys, don't try this at home!"

Precisely, and undefined behaviour means precisely the same thing from
this point-of-view: don't do it; it doesn't work; career-limiting move;
abuse of the language; bug; or however you want to put it.
Of course, if we're speaking "standardese" we should be precise because
there is a difference between undefined and unspecified just as there is
a difference between mandated and implementation-defined (IMHO the
latter distinction is more important).

But "The C++ Programming Language" is not a standard definition document nor
a detailed discussion about them. I think in the context of the general
style of the book the meaning is clear enough.

--
Salu2

[Victor Bazarov]

James Bannon wrote:

[..]
An auxillary question (just to clarify for my own benefit). I presume
that f(v[i++]) is defined (providing i lies in the interval
[v.begin(), v.end() - 1]?

Yes. Side effects of incrementing 'i' take place just before calling
'f'. The old value of 'i' is used to index 'v' and the result of the
indexing is passed to 'f'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Bannon]

Victor Bazarov wrote:

James Bannon wrote:

>[..]
An auxillary question (just to clarify for my own benefit). I presume
that f(v[i++]) is defined (providing i lies in the interval
[v.begin(), v.end() - 1]?

Yes. Side effects of incrementing 'i' take place just before calling
'f'. The old value of 'i' is used to index 'v' and the result of the
indexing is passed to 'f'.

V

Thanks,
Cheers
Jim

[Michiel.Salters]

Salt_Peter wrote:

av*******@gmail.com wrote:

In "Bjarne Stroustrup's C++ Style and Technique FAQ" at:
http://www.research.att.com/~bs/bs_f...aluation-order

for the statement:
f(v[i],i++);

he says that "the result is undefined because the order of evaluation
of function arguments are undefined".

But AFAIK, the order of evaluation of function arguments is unspecified
as the C++ Standard says:
"5.2.2 Function
The order of evaluation of arguments is unspecified."

So isn't he wrong at this?

I think it is undefined because the value of 'i' is accessed and also
moidified within the sequence point and hence it is undefined.

Sharath A.V

Both he and the standard are saying the same thing.
How can you modify and access a variable simultaneously? Thats
impossible.

Not for modern CPUs. They can execute the two instructions at the same
time. The results will be surprising, though, unless you have the CPU
manual.
Of course, that doesn't mean the compiler will tell the CPU to do so.

What he and the standard are saying is that no restriction is imposed
on the compiler to first evaluate one argument and then the other in
any particular sequence.

Not exacly. Unspecified would be any order, as long as the
result would be equal to that of any sequential execution.
Undefined would imply that any result - including a CPU exception -
is OK, from a standard point of view.

I disagree with your intepretation as well.
v[i] is a particular element in a container

You may disagree. The C++ standard says that v[i] is an expression.
Evaluation of that expression may give you an element from a container
if no undefined behavior happens.

Michiel.