65 ms·

Exceptions in C++ are the closest we have to the implementation of the COME FROM proposed in "A Linguistic Contribution to GOTO-less programming". It takes sta

by 112233 2y ago

Exceptions in C++ are the closest we have to the implementation of the COME FROM proposed in "A Linguistic Contribution to GOTO-less programming". It takes statically typed C++ and turns it into dynamically typed language. Throwspec is dead, anything can throw, except when noexcept, then nothing can throw. It is next to impossible to reason about control flow. Dynamic linking opens whole new dimension of this wormcan. Do you handle exceptions in your constructors? How about constructors of your function arguments? Not to mention the non-trivial cost in code size, that makes exceptions a non-option for embedded use.

jacobp100 2y ago
Noexcept is the biggest scam. It basically wraps every call to a noexcept function in a try/catch, and calls terminate in the catch. Actively harmful for performance
- consteval 2y ago
  My understanding of exceptions implementation in C++ is that there's zero performance cost if an exception isn't thrown. Try... catch isn't implemented as a branch, I believe.
  - 112233 2y ago
    There indeed is zero perfomance cost. Code size cost, however, can be astonishing.
- favorited 2y ago
  [[noexcept]] was never intended to be a standalone performance boost for arbitrary functions – it was proposed & accepted so container types could make the "strong guarantee" (of the so-called Abrahams guarantees): operations can fail, but failed operations have no side-effects. It allows, for example, std::vector's resize operation to move its contents rather than copying them, iff its element's move constructor is [[noexcept]]. If the move constructor could throw, the items must be copied so the original buffer is unchanged until the entire copy transaction is complete. std::move_if_noexcept <https://en.cppreference.com/w/cpp/utility/move_if_noexcept https://en.cppreference.com/w/cpp/utility/move_if_noexcept> "N3050: Allowing Move Constructors to Throw (Rev. 1)" (2010) <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n30...> "P2861R0: The Lakos Rule – Narrow Contracts and noexcept Are Inherently Incompatible" (2023) <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2861r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28...> "P2946R1: A Flexible Solution to the Problems of noexcept" (2024) <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2946r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p29...>

by 112233 2y ago

jacobp100 2y ago

Noexcept is the biggest scam. It basically wraps every call to a noexcept function in a try/catch, and calls terminate in the catch. Actively harmful for performance

consteval 2y ago
My understanding of exceptions implementation in C++ is that there's zero performance cost if an exception isn't thrown. Try... catch isn't implemented as a branch, I believe.
- 112233 2y ago
  There indeed is zero perfomance cost. Code size cost, however, can be astonishing.
favorited 2y ago
[[noexcept]] was never intended to be a standalone performance boost for arbitrary functions – it was proposed & accepted so container types could make the "strong guarantee" (of the so-called Abrahams guarantees): operations can fail, but failed operations have no side-effects. It allows, for example, std::vector's resize operation to move its contents rather than copying them, iff its element's move constructor is [[noexcept]]. If the move constructor could throw, the items must be copied so the original buffer is unchanged until the entire copy transaction is complete. std::move_if_noexcept <https://en.cppreference.com/w/cpp/utility/move_if_noexcept https://en.cppreference.com/w/cpp/utility/move_if_noexcept> "N3050: Allowing Move Constructors to Throw (Rev. 1)" (2010) <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n30...> "P2861R0: The Lakos Rule – Narrow Contracts and noexcept Are Inherently Incompatible" (2023) <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2861r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28...> "P2946R1: A Flexible Solution to the Problems of noexcept" (2024) <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2946r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p29...>