Execution sequence with postfix increment and pass by reference

[Marcel Müller]

Hi,


I have a question about the execution sequence of the postfix increment
operator with respect to a function call.


void foo(int type, int*& data);

int* sequence;

foo(*sequence++, sequence);


Is the operator++ always executed before the function foo is called?
In this case the evaluation of the two arguments is independent,
otherwise the value of data in the body of foo is undefined.


Marcel

 

[puzzlecracker]

Hi,

I have a question about the execution sequence of the postfix increment
operator with respect to a function call.

void foo(int type, int*& data);

int* sequence;

foo(*sequence++, sequence);

Is the operator++ always executed before the function foo is called?
Yes
In this case the evaluation of the two arguments is independent,
otherwise the value of data in the body of foo is undefined.

The order of argument evaluation is undefined in C++. However, the
called function will receive the final product.

 

[Stefan Ram]

(and after the evaluation of all arguments), so inside the function the
'sequence' already has the incremented value, and there is no undefined
behaviour.

Possibly not indefined, but at least unspecified.

The second argument might be evaluated before the
first is being evaluated.

For example, an implementation might print

a
a

, another one might print

a
b

, when executing

#include <iostream>
#include <ostream>

void o( char const x, char const * const x1 )
{ ::std::cout << x << '\n';
::std::cout << *x1 << '\n'; }

int main()
{ char const * sequence = "abc";
o( *sequence++, sequence ); }

.

 

[James Kanze]

Possibly not indefined, but at least unspecified.

The second argument might be evaluated before the
first is being evaluated.

That doesn't change anything in the original example (which was,
I suspect, the original poster's point).

For example, an implementation might print

, another one might print

, when executing

#include <iostream>
#include <ostream>

void o( char const x, char const * const x1 )
{ ::std::cout << x << '\n';
::std::cout << *x1 << '\n'; }

int main()
{ char const * sequence = "abc";
o( *sequence++, sequence ); }

.

And a third might core dump, since this code has undefined
behavior; you're modifying sequence *and* accessing it other
than to determine the new stored value, without an intervening
sequence point.

 

[Stefan Ram]

This example not not what the OP gave.

You are right. I was inferring the type of the second argument
from the call, but I should have read it from the declaration.

 

[Jerry Coffin]

[ ... ]

First of all, there is no such thing as "unspecified behaviour".

Oh? Did somebody remove section 1.3.13 from your copy of the standard?

 

[Marcel Müller]

I hope you change the value of 'sequence' to point to something valid
before the call to 'foo' here, otherwise you're dereferencing and
incrementing an uninitialised pointer.

Of course.

Yes, but you should not ask about when it's executed, but when the value
of the object changes. The change in the value is the side effect, and,
luckily for you, there is a sequence point before the function is called
(and after the evaluation of all arguments), so inside the function the
'sequence' already has the incremented value, and there is no undefined
behaviour.

Thanks! That is what I wanted to know.

It makes it a bit easier to unpack ugly, proprietary structures into
reasonable objects.


Marcel

 

[Jerry Coffin]

[ ... ]

First of all, there is no such thing as "unspecified behaviour".

Oh? Did somebody remove section 1.3.13 from your copy of the standard?

OK, you got me. The Standard is full of errors and dualities, AFAICS.
In most of the text it's the value that is unspecified, or the order,
but I haven't see many places where "behavior" is "unspecified". There
is however, a surprising mix-up, see 5/4, the example, which leads me
to believe that even the writers of the Standard couldn't make up their
minds in some situations.

This is, unfortunately true. I'm pretty sure the problem is less that
the writers of the standard don't know what they want, than that they
(or, at any given time, mostly "he", right now Pete Becker) have roughly
10 quadrillion things that really need to be done, and not quite enough
hours in the day to do it. Pete seems to be a pretty good editor, but
going through a document the size of the standard to verify that
everywhere you meant "unspecified behavior", you really used exactly
that phrase (and likewise with "undefined", etc.) is a serious pain at
best -- and there are almost always other things that take priority,
simply because as long as it uses "unspecified" or "undefined" it's
pretty apparent to most people what's being referred to, even if the
next word isn't spelled "behavior".

 

[James Kanze]

[ ... ]
First of all, there is no such thing as "unspecified behaviour".
Oh? Did somebody remove section 1.3.13 from your copy of the standard?

OK, you got me. The Standard is full of errors and dualities, AFAICS.
In most of the text it's the value that is unspecified, or the order,
but I haven't see many places where "behavior" is "unspecified". There
is however, a surprising mix-up, see 5/4, the example, which leads me
to believe that even the writers of the Standard couldn't make up their
minds in some situations.

This is, unfortunately true. I'm pretty sure the problem is
less that the writers of the standard don't know what they
want, than that they (or, at any given time, mostly "he",
right now Pete Becker) have roughly 10 quadrillion things that
really need to be done, and not quite enough hours in the day
to do it.

Not to suggest that Pete doesn't have a sufficient real work in
editing, but the title of the role is "project editor" for a
reason. A lot of the wording is taken verbatim from the
proposals (and a good proposal does provide exact wording).
Which means that often, the left hand doesn't know what the
right hand is doing, and it really is too much to expect Pete
(or Andy Koenig, before him, or any mortal human being) to spot
all of the inconsistencies.

FWIW: there is one certain case of "unspecified behavior" in the
C standard: casting an integral type to a signed integral type,
when the results don't fit. C90 said "unspecified value", but
it was acknowledged by the C committee that this was poor
wording, and the intent was also to allow the error to be
trapped.

There are probably others, but I don't have all of the standard
in memory, so I can't be sure.

 

[Jerry Coffin]

[ ... ]

Not to suggest that Pete doesn't have a sufficient real work in
editing, but the title of the role is "project editor" for a
reason. A lot of the wording is taken verbatim from the
proposals (and a good proposal does provide exact wording).
Which means that often, the left hand doesn't know what the
right hand is doing, and it really is too much to expect Pete
(or Andy Koenig, before him, or any mortal human being) to spot
all of the inconsistencies.

Right -- I certainly didn't mean to imply that any such problem was
Pete's fault or anything like that -- only that the project editor is
(to a large extent) the only one in a good position to see the whole
picture. To a large extent, the project editor makes the changes
approved by the committee. Some proposals work very hard at maintaining
global consistency (some I've seen from Beman Dawes appear to work
particularly hard in that respect). Others just try to restrict
themselves to minimizing the possibility of introducing any new
inconsistencies by minimizing the scope of changes they make at all.

Getting back to the previous question, despite my pointing out the
definition of "unspecified behavior", the comment to which I replied
appears essentially accurate -- even though the term is defined, the
only places in the current standard that I can find the phrase
"unspecified behavior" used are 1) the definition of the term, and 2)
the table of contents entry that points at the definition of the term.

Outside of that, there are a couple hundred uses of "unspecified", but
none of them is followed immediately by "behavior", and looking at a few
dozen, there's not an easy way to change most of them to use the defined
phrase either.