5 ms·

The "care" seems to just be "thing that looks like a value type is a value type." I'm not sure why the author would have ever expected anything different?

CoastalCoder 4y ago
> I'm not sure why the author would have ever expected anything different? Perhaps the message is aimed at less experienced C++ programmers?
omnicognate 4y ago
Yeah, that's the whole point of std::optional. Pointers (including smart ones) have the possibility of being empty/pointing-to-nothing built in. std::optional adds it to value types. To avoid tons of unnecessary copies use move semantics, which std::optional of course supports.
jay-barronville 4y ago
Fair point, but I didn’t gather that the author expected anything different; I think he simply wanted to highlight a behavior that may not be that obvious to programmers who aren’t expert C++ programmers (i.e., most programmers).
- kllrnohj 4y ago
  But why focus on optional then instead of just passing anything by-value? And why not actually dive into when/where this could be of a concern and how to recognize it? It seems like an article aimed neither at beginners nor experts.
flohofwoe 4y ago
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 (e.g. you need to know how std::string is implemented internally, and that a copy operation may or may not be expensive, maybe depending on the length of the payload, compiler and stdlib implementation, etc etc...). And while the fabled 'zero cost abstraction' often is able to clean up the mess (at the cost of high build times), a small and innocent looking change in the surface code may throw things out of whack again and suddenly you have an unexpected performance regression.
- bluGill 4y ago
  Most languages don't let you reason about such things. You just copy things around with no clue or care if it is fast or slow. Most problems don't need that level of reasoning, but when it matters C++ gives you a lot of power to ensure you can control when it happens.
  - jay-barronville 4y ago
    I mean, 9x out of 10, the very reason to use a low-level language like C++ is precisely because you want or need to reason about such things, no?
    - bluGill 4y ago
      Hopefully. There are other low level tasks (device drivers) that you might not care, but need C++'s ability to get close to the hardware for, but in general C++ is for when you need both abstractions and the ability to control performance. (Rust, C, ada, and other such languages also play in this space as well, which is best is not something I can comment on)
- kllrnohj 4y ago
  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

CoastalCoder 4y ago

> I'm not sure why the author would have ever expected anything different? Perhaps the message is aimed at less experienced C++ programmers?

omnicognate 4y ago

Yeah, that's the whole point of std::optional. Pointers (including smart ones) have the possibility of being empty/pointing-to-nothing built in. std::optional adds it to value types. To avoid tons of unnecessary copies use move semantics, which std::optional of course supports.

jay-barronville 4y ago

Fair point, but I didn’t gather that the author expected anything different; I think he simply wanted to highlight a behavior that may not be that obvious to programmers who aren’t expert C++ programmers (i.e., most programmers).

kllrnohj 4y ago
But why focus on optional then instead of just passing anything by-value? And why not actually dive into when/where this could be of a concern and how to recognize it? It seems like an article aimed neither at beginners nor experts.

flohofwoe 4y ago

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 (e.g. you need to know how std::string is implemented internally, and that a copy operation may or may not be expensive, maybe depending on the length of the payload, compiler and stdlib implementation, etc etc...). And while the fabled 'zero cost abstraction' often is able to clean up the mess (at the cost of high build times), a small and innocent looking change in the surface code may throw things out of whack again and suddenly you have an unexpected performance regression.

bluGill 4y ago
Most languages don't let you reason about such things. You just copy things around with no clue or care if it is fast or slow. Most problems don't need that level of reasoning, but when it matters C++ gives you a lot of power to ensure you can control when it happens.
- jay-barronville 4y ago
  I mean, 9x out of 10, the very reason to use a low-level language like C++ is precisely because you want or need to reason about such things, no?
  - bluGill 4y ago
    Hopefully. There are other low level tasks (device drivers) that you might not care, but need C++'s ability to get close to the hardware for, but in general C++ is for when you need both abstractions and the ability to control performance. (Rust, C, ada, and other such languages also play in this space as well, which is best is not something I can comment on)
kllrnohj 4y ago
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