[Interest] Operator QMap<uint, uint>[] is casting to int?

Thiago Macieira thiago.macieira at intel.com
Wed May 8 07:56:16 CEST 2019


On Tuesday, 7 May 2019 14:25:05 PDT Roland Hughes wrote:
> > If there's ever an STL2 (std2 namespace), it'll use signed.
> 
> It's not just mixing C++ APIs. It is interfacing with devices which use
> unsigned octates in groups for the size followed by a contiguous block
> of octates for the data. When they accept text input it has to be sent
> this way and when they communicate text responses it comes back this way.

Data is different. std::byte is unsigned and "unsigned char" is the actual 
definition of byte. QByteArray should actually get an API to treat its 
contents as bytes, not just chars.

But we weren't talking about data, we were talking about metadata: sizes, 
indices, offsets.

> There are also the big data blocks like X-RAY/MRI images and such which
> need to be loaded into larger than signed int containers for manipulation.

Then you use a 64-bit signed integer for that. That's why Qt uses qint64 for 
file sizes, regardless of architecture. 

I can't think of a single use-case that would require the use of all 64 bits 
for the number, instead of 63 and leaving one for the sign. And if you really 
needed to represent numbers over 2^63, it's quite likely you need more than 
2^64 soon, so you had better come up with your own BigInt class for storing 
the information.

Quite frankly, the only reason to use 64-bit unsigned is to use the type as a 
bit pattern storage, such as what QRandomGenerator64::generate() returns.

> I haven't dug under the hood but I wonder if this impacts memory mapping of
> files. Maybe not if there is no container.

Absolutely not. You'd need to have files bigger than 2^63 for that to make 
sense. And mmap takes an off_t as the offset of the file to be mapped, which 
is a signed type.

> The ptrdiff_t comment earlier is a red herring.
> 
> https://en.cppreference.com/w/cpp/types/ptrdiff_t
> 
> typedef /*implementation-defined*/ ptrdiff_t;

In theory, sizeof(ptrdiff_t) and sizeof(size_t) and sizeof(void*) do not need 
to be the same. In fact, the size of the pointer was indeed different on 16-
bit DOS.

But in practice, in all modern architectures, and especially in all 
architectures Qt runs, has run, and will likely ever run, the three have the 
same size. And because of that, the size of the largest object and largest 
memory allocation is half the virtual memory address space.

It is possible to mmap() more than 2 GB of a file in a 32-bit Linux system, 
but a memory map is not a C++ object or a C++ memory allocation.

> Some shops won't or cannot let you use an int.
> 
> If they are changing from int to q-whatever defined type there will
> probably be some compilation cleanup anyway so unsigned wouldn't be bad
> unless someone is cheating somewhere and initializing size to -1

qsizetype is signed and will remain so. We want to transition Qt containers to 
support more than 2 GB on 64-bit systems, so we want to use qsizetype. What's 
missing is implementing this and finding all the wrong casts.

PS: would you please reply with the correct subject?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products





More information about the Interest mailing list