3

Can compiler reorder variable setting and throw() op in C++? Or, does standard C++ 14882-1998 allows or prohibit compiler of this transform?

For code:

bool funct()
{
    bool succeeded = false;
    bool res_throw = false;

        try {
            throw("it");
            succeeded = true;
        }
        catch(...) {
            res_throw = true;
        }

        cout << "Result of throw: " << res_throw << endl;
        cout << "succeeded: " << succeeded << endl;

    return succeeded;
}

Can the output be a

Result of throw: true
succeeded: true

The Standard says: "[intro.execution]#7":

modifying an object .. are all side effects, which are changes in the state of the execution environment

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

Is throw statement a sequence point?

osgx
  • 90,338
  • 53
  • 357
  • 513

2 Answers2

4

The semicolon is a sequence point. The throw happens before succeeded is set to true

EDIT: To clarify: succeeded will not be set to true

John Dibling
  • 99,718
  • 31
  • 186
  • 324
4

Yes, there is a sequence point associated with the throw statement, because there is a sequence point at the end of every statement.

So succeeded must remain false in your example.

I don't have the C++98 Standard, but in the C++03 Standard:

1.9p16: There is a sequence point at the completion of each full-expression.

A statement is the simplest kind of "full-expression", but the Standard is worded to include other expressions that are not technically part of any statement.

aschepler
  • 70,891
  • 9
  • 107
  • 161
  • So, every `;` after the statement is a seq. point? Even `Jump statements` ? – osgx Dec 06 '10 at 17:52
  • 1
    Good catch. Technically not every statement is a full-expression. `break;`, `continue;`, `return;`, `goto label;`, and some declarations like `int x;` do not contain or implicitly use any syntactic expressions. – aschepler Dec 06 '10 at 17:58
  • In my case, `Throw` is defined as expression in 5.17 [expr.ass] "assignment-expression: throw-expression" & 15 [except] "throw-expression: `throw` assignment-expression_opt" – osgx Dec 06 '10 at 18:02
  • http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ compiling this with "gcc -O2 -S" using gcc 4.0, or icc. Both will do the store to Ready first, so it can be overlapped with the computation of i/10. The reordering is not a compiler bug. It's an aggressive optimizer doing its job. – osgx Dec 13 '10 at 16:08
  • @osgx: That quoted article is different. In that case, the optimizer is allowed to reorder statements because of the "as if" rule, Standard section 1.9. In your example, the program tests whether the value changed, so it must be correct. In the quoted example, there's no way for the program itself to act differently when the statements are reordered, so the optimizer can do what it wants. (Multithreaded programs are beyond the scope of C++98 and C++03, but the draft C++0x Standard does allow multithreaded programs, and any results depending on another thread are usually unspecified.) – aschepler Dec 13 '10 at 19:50