Care is needed to use C++ std:optional with non-trivial objects

Re:Care is needed to use C++ std:optional with non-trivial o... by cesarb on Friday January 13, 2023 @08:37AM (#34367436)

> 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.

[ Parent | on HN ]

Re:Care is needed to use C++ std:optional with non-trivial o... by kllrnohj on Friday January 13, 2023 @08:39AM (#34367464)

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?

[ Parent | on HN ]

Re:Care is needed to use C++ std:optional with non-trivial o... by rightbyte on Friday January 13, 2023 @11:08AM (#34369726)

It adds a space overhead.

A pointer is already an optional type by the 0 convention.

[ Parent | on HN ]

Re:Care is needed to use C++ std:optional with non-trivial o... by kllrnohj on Friday January 13, 2023 @02:23PM (#34372594)

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/n35... ), even though boost::optional supported them

[ Parent | on HN ]