I’m not totally sold on the idea that “unsigned for value range” is an anti pattern. Sure, in the example the author presents (std::string::find), it definitely is. But now with std::optional in C++ 17, it seems perfectly fine to use an unsigned value for range.
std::string:find could simply return a std::optional<size_t>, for example.
Does anyone see a problem with this approach that I do not? Not considering backwards compatibility.
To me the first obvious drawback of optional<size_t> is that it doubles the size requirements. On 64bit machine this will typically grow from sizeof(size_t) == 8 to sizeof(std::optional<size_t>) == 16.
I’m not totally sold on the idea that “unsigned for value range” is an anti pattern. Sure, in the example the author presents (
std::string::find), it definitely is. But now withstd::optionalin C++ 17, it seems perfectly fine to use an unsigned value for range.std::string:findcould simply return astd::optional<size_t>, for example.Does anyone see a problem with this approach that I do not? Not considering backwards compatibility.
To me the first obvious drawback of
optional<size_t>is that it doubles the size requirements. On 64bit machine this will typically grow fromsizeof(size_t) == 8tosizeof(std::optional<size_t>) == 16.