3 ms·

What innocent looking change are you thinking of that becomes an issue as a result of this? If your function is currently taking a parameter by-value, and you

What innocent looking change are you thinking of that becomes an issue as a result of this? If your function is currently taking a parameter by-value, and you replace it with std::optional<T>, you're still taking it by value and doing the exact same amount of copies. No (new) issues from optional. You only run into trouble if you do something like change `void foo(const T&)` to 'void foo(std::optional<T>)`. But in such a change, it's "clear" (insofar as C++ is ever clear about anything) you're replacing a reference parameter with a value parameter. I don't think this is surprising std::optional behavior? > The (typical C++ stdlib) problem here is that things that look deceptively simple on the surface may result in a surprising amount of activity under the hood It's literally exactly what it looks like. The C++ stdlib didn't complicate or obfuscate anything.

cesarb 4y ago
> What innocent looking change are you thinking of that becomes an issue as a result of this? In these contexts, the "innocent looking change" is usually something which pushes a method over an inlining threshold, so that something which used to be inlined no longer is, and a zero cost abstraction suddenly has a cost larger than zero.
- kllrnohj 4y ago
  That can be about literally any change, how does std::optional meaningfully change things here to warrant calling out that you need care when using it specifically?
  - rightbyte 4y ago
    It adds a space overhead. A pointer is already an optional type by the 0 convention.
    - kllrnohj 4y ago
      Yeah but I'd file that under C++'s ABI problems category. I don't think anything in std::optional's spec requires that it has additional padding. It could have an optimized representation for known types of T & thus specialize T* to use nullptr as the sentinel instead of an extra boolean, similar to how std::vector specializes for bool (although that one is probably a mistake, but whatever). But unfortunately also optional references was never resolved & thus punted ( see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3527.html#rationale.refs https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n35... ), even though boost::optional supported them

cesarb 4y ago

> What innocent looking change are you thinking of that becomes an issue as a result of this? In these contexts, the "innocent looking change" is usually something which pushes a method over an inlining threshold, so that something which used to be inlined no longer is, and a zero cost abstraction suddenly has a cost larger than zero.

kllrnohj 4y ago
That can be about literally any change, how does std::optional meaningfully change things here to warrant calling out that you need care when using it specifically?
- rightbyte 4y ago
  It adds a space overhead. A pointer is already an optional type by the 0 convention.
  - kllrnohj 4y ago
    Yeah but I'd file that under C++'s ABI problems category. I don't think anything in std::optional's spec requires that it has additional padding. It could have an optimized representation for known types of T & thus specialize T* to use nullptr as the sentinel instead of an extra boolean, similar to how std::vector specializes for bool (although that one is probably a mistake, but whatever). But unfortunately also optional references was never resolved & thus punted ( see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3527.html#rationale.refs https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n35... ), even though boost::optional supported them