Re: Boost.StaticString (formerly Boost.FixedString) is ready for release!

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-02-28 15:47:38

TLDR: I'm contra signed-sizes. The size type is size_t and it's unsigned 
for a reason: There exists no negative size. If you get an unsigned 
value there is no need to check for below zero, if you get a signed 
value you might. It is the same there is `not_null<T>` in GSL(?).

The whole discussion just shows that there is a problem with operations 
mixing signed and unsigned types in C++ in general.
What we probably wanted was something like `size_t = not_negative<int>`, 
but well...

Am 28.02.20 um 16:08 schrieb degski via Boost:
>
>   Yes, maybe (did you measure ?), but it does away with the 'comparing
> signed to unsigned' and the UB on signed overflow, does allow for
> optimizations.'
I can pass that back: Did you measure the benefit of those UB-based 
optimizations?
> Suppose you need to
> store some (or many of those indexes (of type std::size_t), the better
> cache-locality (and lower memory use), will affect your performance.
You mean using a 16- or 32-bit type as the size? Well there might be use 
cases for >4GB of "strings", although that's conceived.
But curious: What usecase requires you to store that many indices that 
this matters?
>   There
> are certainly more use-cases. std::span almost had a ssize() param, but in
> the end (I believe) holding on to the past seems more important.
I think it's more about consistency. But yes, due to the rules for 
mixing signed/unsigned ops this would have helped.
> I have never in my life seen a vector of size 2^32, even an array of chars
> that size is huge. The STL-solution to use std::size_t is totally arbitrary
Is it? size_t used to be 32 bits unsigned. That is the most reasonable 
choice. The next better would be 16bit but I'm sure we agree that this 
would be to small.
And in absence of a not_negative<int> a size is unsigned as is the 
underlying value space.
> there is always std::int64_t
Not necessarily. IIRC it is optional
> With std::size_t's we easily introduce UB (and a bad one for
> that matter, because the wrapping of un-signed's might get unnoticed
> (luckily there is a warning, but nothing stops you from ignoring it)).
With ranges and range-based for loops the operations on a size become 
less frequent. And it is easier to teach: Requesting a size? You'll get 
an unsigned value because it can never be negative.
It avoids ambiguity. Compare that to a function returning a pointer: Are 
you supposed to check that for NULL or can you assume it never is?