What's a sequence point?

[Smart Tag]

What's a sequence point?

[ C++ Standard Sec 1.9.7]
"At certain specified points in the execution sequence called sequence
points, all side-effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place."

Can you please elaborate what this means?

Thanks!

 

[Alf P. Steinbach]

* Smart Tag:

What's a sequence point?

[ C++ Standard Sec 1.9.7]
"At certain specified points in the execution sequence called sequence
points, all side-effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place."

Can you please elaborate what this means?

A side effect is for example an update of a variable, i.e., at certain points
called sequence points, like between two statements, you're sure that all
earlier requested variable updates have been performed.

Mostly this ties in with C++'s archaic/historical notion that the compiler can
do a much better job of optimization if it's left free to rearrange the order
that things happen in.

Obviously, after sequence point A it can only rearrange things that happen
before the next sequence point B, because at B the total effect has been
achieved -- nothing that was specified to happen between A and B can be moved
after B (at least not unless the compiler can prove that you can't notice).

But, between sequence points all sorts of things are allowed to happen, like in
the quantum foam between measurements of the spin of an electron.

And if your program depends on any assumption about the state of things in
between sequence points, like e.g. that surely this "++" has been performed,
then it will be like some assumption about the state of the quantum foam of the
universe between measurements: it may work, or crash, or cause nasal demons to
fly out of your nose, whatever, generally called Undefined Behavior.


Cheers & hth.,

- Alf

 

[AnonMail2005]

What's a sequence point?

[ C++ Standard Sec 1.9.7]
"At certain specified points in the execution sequence called sequence
points, all side-effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place."

Can you please elaborate what this means?

Thanks!

The && logical operator is an example of a sequence point. The first
expression before the && is completely evalutated before it moves on
the next expression. Compare this to an assignment operator which is
not a sequence point.

I've never seen a good treatment of sequence points except for
Advanced C: Tips and Techniques by Paul Anderson and Gail Anderson.
It's an old book, I think out of print but it you can find it on the
web. It's C but most of what it says about sequence points and other
things (e.g. C arrays) also applies to C++. It is well worth reading.

HTH

 

[Joe Smith]

Mostly this ties in with C++'s archaic/historical notion that the compiler
can do a much better job of optimization if it's left free to rearrange
the order that things happen in.

Obviously, after sequence point A it can only rearrange things that happen
before the next sequence point B, because at B the total effect has been
achieved -- nothing that was specified to happen between A and B can be
moved after B (at least not unless the compiler can prove that you can't
notice).

Which of course it often can prove exactly that. Once the compiler has
converted the code to SSA form, it is very often extremely clear what could
and what could not be noticed. The simple fact is that those rules make
avoiding inadvertantly invoking UB make easier than would otherwise be the
case, while in extremely few cases does it enable better optimization.

That is of course talking about modern compilers. Early compilers could do
very little optimization and relied on those rules quite a bit.

I'd like to see the difference in a modern compiler if strict sequencing
were required, versus the sequence point rules. It would probably be hard to
notice the difference except in a few very specific cases. These sorts of
rules become much more important again under multi-threading, which is why
that whole section of the standard was heavilly re-written for C++0x.

Changing write ordering can be a problem in multithreaded applications on
all platforms, and things only get worse when the platform does not by
default guarentee cache consitancy and order of memory operations, requiring
complications like memory barriers, explic cache flushes, and more. If all
went well few programmers would need to worry too much about these details,
beyond being aware that they are going on under the hood, but in reality
dealing with these complications can take far too much time of even
Application Programmers, not just Systems Programmers like the threading
library author.