C++: 'cout << pointer << ++pointer' generates a compiler warning

Question

I have a C++ learning demo here:

char c = \'M\';
short s = 10;
long l = 1002;
char * cptr = &c;
short * sptr = &s;
long * lptr = &l;
cout <&         


        

Answer 1

Since C++17 the code is correct.

Prior to C++17 the evaluation of operands of a << chain was unsequenced, so the code caused undefined behaviour.

The compiler warning suggests you are not compiling in C++17 mode. To fix it you could either:

• Compile in C++17 mode, or
• Separate the << chain into multiple cout << statements where there is not x and ++x within the same statement.

---

Note: As of now, all versions of g++ seem to be bugged and not implement these sequencing requirements correctly, see this thread for some more examples. The warnings can be seen as indicating the compiler bug; they are not just bogus warnings.

Answer 2

According to C++ Standard Draft Paper N4762 (2018-07-07) on page 68 in section § 6.8.1/10

( or [intro.execution]/10 on eel.is website here )

Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced.

---

For statement

cout << c << '\t' << static_cast<void*>(cptr) << '\t' << static_cast<void*>(++cptr) << '\n';

that means c++ compiler can not guarantee that static_cast<void*>(cptr) will be evaluated before ++cptr on the right because they are all operands on the same statement.

So you can force their sequential order of execution simply by ordering them in ordered and separated statements.

For example :

cout << c << '\t' << static_cast<void*>(cptr) << '\t'; cout << static_cast<void*>(++cptr) << '\n';

[ compiler explorer ]

---

Update

As M.M's answer states that c++17 now guarantees operand evaluation sequence of <<

It turns out that GCC 8.1 doesn't warn, even with std=c++11, unless with -Wall and always warns with -Wall

While clang 6.0 warns "no matter what".

[ compiler explorer ]

So, as well as -std=c++17, you must also provide option -Wno-unsequenced to suppress it :

• if you are on clang 6.0
• if you are on gcc 8.1 with -Wall

Answer 3

You re having undefined behavior in lines 18, 19, 20. Cause of the result of executing the line will be different depending on whether ptr or ++ptr is evaluated first.