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

[Roland Hughes]

On 5/9/19 3:22 AM, Thiago Macieira wrote:
> 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.
I was talking about the devices needing the sizes sent in unsigned 
octates. Sorry if there was any confusion. The static casts most often 
occur here.
>> 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.
Or the size incoming and outgoing is required to be unsigned and it is 
to/from a device where one does not control the firmware.
>
>> 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?

Sorry about that. I get the list in digest form and have been 
significantly time restricted. Putting in a lot of effort on current 
medical device and documenting static casts in a manner which will pass 
scrutiny during FDA formal review. (Not as simple as it sounds.) I don't 
know where the "limit" for these is. Thankfully, knock knock knock on 
wood, I've never had the rejection. Perhaps another here with experience 
on a project that didn't pass review can shed light on where the 
threshold lies?

We really really really need those things which cannot be negative to be 
unsigned. I understand there is great resistance to this for reasons 
which make no sense when viewed from the place of one who actually has 
to interface with this stuff.

As a compromise, every container should have a usize() method which 
returns the value as an unsigned datatype. To make things even more 
bullet proof it could be something like

usize( bool * wasNegative = nullptr)

ulength(bool * wasNegative = nullptr)

just in case someone has been playing games with -1 somewhere that would 
give us the ability to trap.

Such a method would remove a mass quantity of static casts in the device 
code itself thus removing all of the documentation and pain associated 
with getting such code through the formal review process.

Then we only have to jump through hoops for things like DICOM.

https://www.dicomstandard.org/faq/

====

Following the (group number, data element number) pair is a length field 
that is a 32 bit unsigned even integer that describes the number of 
bytes from the end of the length field to the beginning of the next data 
element.

====


-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com