Boost logo

Boost :

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
> 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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at