1. 2

  2. 1

    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++ :-/

    1. 1

      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.