Execution sequence with postfix increment and pass by reference

[=?ISO-8859-1?Q?Marcel_M=FCller?=]

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

[Victor Bazarov]

Marcel Müller wrote:

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);

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.

Is the operator++ always executed before the function foo is called?

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.

In this case the evaluation of the two arguments is independent,
otherwise the value of data in the body of foo is undefined.

Not sure what "independent" means here. 'data' argument is a reference
that needs to be initialised. The evaluation of the second argument is
essentially a no-op.

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

[James Kanze]

On Jul 18, 10:28 pm, [e-mail] (Stefan Ram) wrote:

Victor Bazarov <[e-mail]:

>o(*sequence++, sequence);

(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.

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

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 ); }

.

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <g5**********@news.datemas.de>, v.********@comAcast.net
says...

[ ... ]

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?

--
Later,
Jerry.

The universe is a figment of its own imagination.

[=?ISO-8859-1?Q?Marcel_M=FCller?=]

Victor Bazarov wrote:

Marcel Müller wrote:

>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);

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.

>Is the operator++ always executed before the function foo is called?

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]

In article <7cc41178-ef83-47d5-883f-f7beb4a496fa@
25g2000hsx.googlegroups.com>, ja*********@gmail.com says...

[ ... ]

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.