-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> I don't understand the obsession with constructors.
The article describes how smart pointers are more difficult to use for opaque/POD structs without destructors. Correct me if I'm wrong, but I think types with destructors generally require constructors too (though you can sometimes rely on default destructors/constructors, by holding fields which themselves have destructors/constructors).
> Fallible placement initialisation into allocated memory is something that I honestly don't know a good use case for. It's certainly not something that's very common and I never encountered it.
Understandable. Rust lacks any safe means for placement initialization (even infallible), resulting in stack overflows (often disappearing in optimized release builds) when allocating large heap arrays (because it has to stack-allocate the array, then memcpy to the heap), eg. https://github.com/rust-lang/rust/issues/53827. I haven't encountered this firsthand though.
> It also again boils down to a case of premature optimisation
Copying can be a correctness issue as well as performance. One time I wrote a function which took an object by copy (when I should've passed by reference), and returned a reference to the object, resulting in a use-after-free. Additionally mutating a copy doesn't mutate the original object, unlike a non-const reference.
In my C++ code, I've copied Rust and expressed fallible initialization by returning a std::optional from a static method (which the article failed to mention). The problem is that (like Rust) you lose placement initialization, and (unlike C++ or Rust) you can't initialize private fields using aggregate initialization or initializer lists, and must write a passthrough constructor (which can't even be private because it breaks make_unique).
https://github.com/hsutter/708 is a C++ proposal which unifies placement constructors and writable out-parameters ("definite first use"). I don't think it makes placement initialization fallible, but I'm not sure.
Using a function pointer as a unique_ptr's deleter type, and passing it in at runtime, makes the unique_ptr fat (two arguments). To avoid this overhead, I prefer passing in a default-constructible type with an operator() deleter function, and not passing in a value into the unique_ptr constructor (https://github.com/nyanpasu64/qvgmsplit/blob/edcce6df391c15b...). A neat party trick is to use the decltype of a lambda (https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_re...).