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.macie...@intel.com> > To: interest@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@qt-project.org > https://lists.qt-project.org/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
