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