3 ms·

Yes, exceptions affect optimizations. The crux is that anything that might throw is a barrier to any other statement with observable side effects before or afte

Yes, exceptions affect optimizations. The crux is that anything that might throw is a barrier to any other statement with observable side effects before or after it. Neither can be moved to the other side of the potential thrower. However, explicit error handling adds a branch and explicit return inatead of a potentially throwing statement, so if the compiler is rightfully pessimistic, no performance is lost. In the other hand, you can make the compiler ignore the potential for exceptions by declaring functions and methods nothrow. This will make the compiler ignore all considerations for potential exceptions in callers and lead to better optimizations in some cases. But sticking nothrow onto things is hard because when a nothrow fuction does happen to throw, you're in UB land.

aw1621107 7y ago
> because when a nothrow fuction does happen to throw, you're in UB land IIRC that was the originally proposed behavior for noexcept, but it was changed at some point to call std::terminate instead.
- gmueckl 7y ago
  Yikes, of course it should be noexcept instead of nothrow in my previous post! However, I don't find any referenc to noexcept having gotten defined behaviour. Do you have any pointers?
  - aw1621107 7y ago
    In the current version of the standard on the GitHub repo [0], Section 14.5 Paragraph 5 says: > Whenever an exception is thrown and the search for a handler (14.4) encounters the outermost block of a function with a non-throwing exception specification, the function std::terminate is called (14.6.1). I don't know when precisely noexcept was changed to call std::terminate, but I did find N3103 (included in the 2010-08 post-Rapperswil mailing [1]), which argued that the standard should require calling std::terminate to avoid security issues. [0]: https://github.com/cplusplus/draft https://github.com/cplusplus/draft [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3103.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n310...

aw1621107 7y ago

> because when a nothrow fuction does happen to throw, you're in UB land IIRC that was the originally proposed behavior for noexcept, but it was changed at some point to call std::terminate instead.

gmueckl 7y ago
Yikes, of course it should be noexcept instead of nothrow in my previous post! However, I don't find any referenc to noexcept having gotten defined behaviour. Do you have any pointers?
- aw1621107 7y ago
  In the current version of the standard on the GitHub repo [0], Section 14.5 Paragraph 5 says: > Whenever an exception is thrown and the search for a handler (14.4) encounters the outermost block of a function with a non-throwing exception specification, the function std::terminate is called (14.6.1). I don't know when precisely noexcept was changed to call std::terminate, but I did find N3103 (included in the 2010-08 post-Rapperswil mailing [1]), which argued that the standard should require calling std::terminate to avoid security issues. [0]: https://github.com/cplusplus/draft https://github.com/cplusplus/draft [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3103.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n310...