on Fri Oct 28 2011, "Stewart, Robert" <Robert.Stewart-AT-sig.com> wrote:
Domagoj Saricj wrote:
On 20.10.2011. 15:15, Stewart, Robert wrote:
Domagoj Saric wrote:
On 19.10.2011. 17:47, Stewart, Robert wrote:
Using (1) on existing code could change behavior.
Again, how could it change behaviour? Unless, again,: "...there is a real world person/problem that depends on the defined std::unexpected/std::terminate behaviour of noexcept as opposed to undefined or implementation defined behaviour of a compiler specific in case "someone violates a promise given about the particular function"..."
State it however you might like, but telling a compiler that a function no longer emits any exceptions can mean changes in optimization, insertion of validation logic, etc., which can *change behavior*.
AFAIK optimization is not allowed to manifest any change in behaviour, and the addition of noexcept already by itself changes/inserts "validation logic" so I still don't see what difference does that make?
Let me try it this way. With (1), we get the following before and after for C++03:
before: void f(); after: void f() compiler-specific-nothrow;
For C++11, (1) inserts noexcept, which was the reason for introducing it.
Because the addition of the compiler-specific-nothrow decoration implies lost optimization opportunities and the addition of validation logic, it can affect client code in undesirable ways.
Rob, I don't know what you mean by "lost optimization opportunities and the addition of validation logic." The only compiler-specific behaviors I know of do the exact opposite: they add optimization opportunities and remove validation logic. Code can use the noexcept operator to detect noexcept-ness of expressions at compile-time and do something semantically different... but it shouldn't. Normally, noexcept should only be used for optimization. -- Dave Abrahams BoostPro Computing http://www.boostpro.com