Title
Optional compile-time evaluation of constant expressions
Status
cd3
Section
7.7 [expr.const]
Submitter
John Spicer

Created on 2012-08-14.00:00:00 last changed 123 months ago

Messages

Date: 2013-04-15.00:00:00

[Moved to DR at the April, 2013 meeting.]

Date: 2012-10-15.00:00:00

Proposed resolution (October, 2012):

Change 7.7 [expr.const] paragraph 4 as follows:

[Note: Although in some contexts constant expressions must be evaluated during program translation, others may be evaluated during program execution. Since this International Standard imposes no restrictions on the accuracy of floating-point operations, it is unspecified whether the evaluation of a floating-point expression during translation yields the same result as the evaluation of the same expression (or the same operations on the same values) during program execution. [Footnote: Nonetheless, implementations are encouraged to provide consistent results, irrespective of whether the evaluation was actually performed during translation and/or during program execution. —end footnote] [Example:...
Date: 2012-08-14.00:00:00

According to the note in 7.7 [expr.const] paragraph 4,

[Note: Although in some contexts constant expressions must be evaluated during program translation, others may be evaluated during program execution. Since this International Standard imposes no restrictions on the accuracy of floating-point operations, it is unspecified whether the evaluation of a floating-point expression during translation yields the same result as the evaluation of the same expression (or the same operations on the same values) during program execution.

With the advent of narrowing rules, which require the compiler to evaluate constant expressions in more contexts than was the case in C++03 in order to determine whether an expression is well formed or not, this wording is not sufficiently clear in stating that even in cases where the computation must be done at compile time, the implementation is free to use the result of a runtime calculation rather than preserving the one computed at compile time.

History
Date User Action Args
2014-03-03 00:00:00adminsetstatus: drwp -> cd3
2013-10-14 00:00:00adminsetstatus: dr -> drwp
2013-05-03 00:00:00adminsetmessages: + msg4395
2013-05-03 00:00:00adminsetstatus: ready -> dr
2012-11-03 00:00:00adminsetmessages: + msg4057
2012-11-03 00:00:00adminsetstatus: open -> ready
2012-08-14 00:00:00admincreate