This is mostly complaining about use of “idiomatic” std::optional results in potentially expensive behaviour constructor calls. The canonical example is the unwrap_or (or whatever it’s called) which instantiates a std::string rather than somehow .. not? But this is a standard foot gun that comes from c++ refusing to actually acknowledge strings should have compiler support. Which is a common issue in c++ :-/
This generally isn’t a problem with std::string because it can be move constructed so the constructions shouldn’t incur a heap allocation. The value method on std::optional returns a reference to the contained object and so there’s no construction there and you can move construct it out.
I still consider having a compiler aware of strings to be an antifeature in a language and C++ does the right thing there. The problem is that the standard library string model is not very good:
It conflates interface and representation. If your standard library does refcounting or does the small-string optimisation and that isn’t appropriate for your use, you are stuck with it. For a lot of workloads, you can get a very big speedup (I’ve seen doubling of transaction throughput rates) by changing the representation of strings to something tailored to your workload. This isn’t possible if you’re using std::string and so a load of libraries add their own, which adds copying overhead everywhere.
It doesn’t support unicode (it now supports unicode storage, but doesn’t even have iterators for unicode code points, let alone glyphs or words).
It is inconsistent about whether simple operations belong as methods or functions that take a templated thing that might be a std::string.
This is mostly complaining about use of “idiomatic” std::optional results in potentially expensive behaviour constructor calls. The canonical example is the unwrap_or (or whatever it’s called) which instantiates a std::string rather than somehow .. not? But this is a standard foot gun that comes from c++ refusing to actually acknowledge strings should have compiler support. Which is a common issue in c++ :-/
This generally isn’t a problem with
std::stringbecause it can be move constructed so the constructions shouldn’t incur a heap allocation. Thevaluemethod onstd::optionalreturns a reference to the contained object and so there’s no construction there and you can move construct it out.I still consider having a compiler aware of strings to be an antifeature in a language and C++ does the right thing there. The problem is that the standard library string model is not very good:
std::stringand so a load of libraries add their own, which adds copying overhead everywhere.std::string.