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

[Jason H]

Hi all,
I'm really sorry I brought this up. I have been working with smaller things thanks size_t.  I was wrong in the general case.

You can do a data structure of 16gB using the range of signed indexes for doubles. That should plenty.

I do still miss the python negative syntax though. [-1] and [-2] in particular. Though I done expect slices to be a thing? Maybe? Eventually?



> Sent: Friday, May 10, 2019 at 6:36 PM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Subject: Re: [Interest] Operator QMap<uint, uint>[] is casting to int?
>
> On Friday, 10 May 2019 04:17:03 PDT Roland Hughes wrote:
> > > 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.
>
> Only if we're talking about sizes between 0 to 255. That's what a single
> unsigned octet can represent. Doesn't strike me as very useful.
>
> If you meant transmitting sizes as unsigned values over the network or medium,
> that's fine, since negative counts are physically meaningless. The bit pattern
> of any size in signed and unsigned is the same, so the choice between them is
> irrelevant. You may as well treat the protocol field as signed.
>
> > > Then you use a 64-bit signed integer for that. That's why Qt uses qint64
> > > for file sizes, regardless of architecture.
> [cut]
> > 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.
>
> Which, just like the above, you can treat as *signed* 64-bit, since your item
> count will not likely be more than 9223372036854775807. If it is, then you
> should use signed 128-bit, not unsigned 64-bit.
>
> I understand your argument that the other side may have specified that the
> field is unsigned. That's fine. But my argument is that all values between 0
> and 9223372036854775807 have the exact same bit pattern in both signed and
> unsigned 64-bit.
>
> However, I can now think of one particular case where unsigned math may be
> useful: dealing with untrusted data (and network definitely is untrusted).
> Until you confirm that all values are in the expected range, you should keep
> it unsigned.
>
> > 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.
>
> No, we do not "really really" need that.
>
> Just because one field can't be negative does not mean that others can't. Take
> the example of a string / vector / bytearray size. As I said above, sizes
> cannot meaningfully be negative. But functions like indexOf() take an offset
> position that can be negative and the function can return a negative value
> indicating that the search failed. Using unsigned for size() is much more
> likely to cause you to need casts, for no appreciable gain since you cannot
> have more items in that vector or string than the maximum signed value.
>
> > 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)
>
> Sorry, not convinced. This is as much an ugly band-aid as std::ssize()
> function.
>
> > 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.
> >
> > ====
>
> This is fine, but since you can't operate on this much data on a 32-bit system
> without implementing windowed access through the data in your own code, I
> don't see as in impediment. You will code your application to deal with a
> possible 4 GB distance by seeking in the file -- and remember off_t is signed!
>
> If you only allow your application on 64-bit systems, then qsizetype can
> represent all 32-bit unsigned values without loss of information.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>