[Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

Ville Voutilainen ville.voutilainen at gmail.com
Wed Dec 5 20:24:25 CET 2018


On Wed, 5 Dec 2018 at 21:11, Jean-Michaƫl Celerier
<jeanmichael.celerier at gmail.com> wrote:
>
> On Tue, Dec 4, 2018 at 8:45 PM Thiago Macieira <thiago.macieira at intel.com> wrote:
>>
>> On Tuesday, 4 December 2018 10:43:31 PST Bernhard Lindner wrote:
>> > Then let me rephrase my opionen: What every you plan to change regarding
>> > size types in Qt6... do it the standard (C++20?) way.
>>
>> We're doing it the way the committee says it should have done in the first
>> place, not the way it has done: signed.
>>
>
> Thanks, underflowing operations on std::containers's size_t have been an unending source of bugs in the projects I work on.
> (thankfully nowadays clang can check for it with -fsanitize=undefined).

That is indeed one argument for a signed type, as opposed to an
unsigned type. For a signed {over,under}flow, a sanitizer can detect
your mistakes. For an unsigned {over,under}flow, it can't, since
there's nothing to sanitize, all behavior is well-defined, sane or
not.

For historical perspective, John Lakos makes this argument (and mostly
every other argument speaking in favor of a signed
type and against an unsigned type) in his very old book, "Large-Scale
C++ Software Design". To repeat, the reason
why the committee keeps insisting span::size() returning a size_type
(which is practically a size_t) is not because we think
it's great, we (well, in the most recent discussion, a consensus
majority of us) just think that span should not be given a
magical exception when everything else returns an unsigned type.

A significant part of the overall concern, at least as far as stdlib
vendors goes, is ABI. We do have the opportunity at Qt 5->6 to break
ABI.
We *are* going to break ABI just by the nature of changing what the
library is to link against, so we have the opportunity to do useful
ABI breaks.
In that sense, we have far less stringent compatibility
requirements/expectations/wishes/aspirations than a stdlib
implementation like
libstdc++ (or to historically less extent, but changing over time,
libc++, and same for msvclib) has.



More information about the Development mailing list