Il 05/05/19 15:07, Roland Hughes ha scritto:
On 5/5/19 5:00 AM, interest-requ...@qt-project.org wrote:It makes for a lot of documentation in the embedded system world where every static_cast<>() has to be documented in the code and justified in a formal code review which produces even more documentation. It also makes for some fancy dancing on 32-bit embedded targets where a uint would be big enough to hold the size of something but an int falls short.No, the size of something definitely fits in int on 32-bit systems. And why do you need to do any static_cast in the first place?
Question: "why do you need any static_cast?".
Virtually every English speaking embedded system shop uses the Barr standard. https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard While each shop tweaks it for C++, C-style casts are explicitly forbidden (at least in every shop I've been at). None can make it through formal review. In their C++ presentation slides the Barr group is a bit softer on their wording. Less so in actuality, but the slides are recorded forever. https://barrgroup.com/Embedded-Systems/How-To/Getting-Started-With-Cplusplus
Answer 1): A standard tells me not to use C-style casts. Does it answer the question? No.
======== Next is type casting, when we use C style cast, there are times when we are just kind of smashing “Square peg into a round a hole” this is potentially dangerous. Because C++ is a lot more finicky about type checking, the compiler will try to catch bad cast for us. There is no way of getting around the need to do type casting. As you move forward, consider always using the C++ cast operators, while these will look a little foreign and you may need to occasionally look up, which one to use in which situation, they are likely to ensure safe cast in your program. As a general rule try to use static cast, this works for most data type casting. Occasionally you will need to use reinterpret cast. It’s a closest thing to a real C style cast. Since we don’t recommend using RTTI, dynamic cast really won’t be of concern to you and we won’t really talk about it here. And then the last one is const cast, which used with extreme caution, this is similar to casting away the constance of an object, so unless you really know that the object you are casting away the constness from can be done safely we recommend being very careful in this area.
Answer 2: what the different kinds of built-in casts are in C++, and what they do.
Does it answer the question? No. (Note that this is quoting Barr, without saying it out loud explicitly).
As to size definitely fitting in an int, we will have to disagree. Sure, if a container is extremely short sighted and using an int internally to keep track of (and therefore limit) each allocated byte, effectively a neutered container, that statement would be correct. It never __SHOULD__ be correct.
Answer 3: an opinion/argument about whether a container should use an int to keep track of its capacity.
Does it answer the question? No.
https://code.woboq.org/gcc/include/limits.h.html ======== /* These assume 8-bit `char's, 16-bit `short int's, and 32-bit `int's and `long int's. */ /* Number of bits in a `char'. */ # define CHAR_BIT 8 ... /* Minimum and maximum values a `signed int' can hold. */ # define INT_MIN (-INT_MAX - 1) # define INT_MAX 2147483647 /* Maximum value an `unsigned int' can hold. (Minimum is 0.) */ # define UINT_MAX 4294967295U
Answer 4: random paste from a file proving that on a particular system a char is 8 bits and int is 32.
Does it answer the question? No.
The biggest physical container one can have is half of maximum physical RAM. A small application can easily need more than that. We can use the old chestnut of image processing which needs to load an entire hi-res image into memory to do some kind of transformation, writing the transformed bytes to a file output stream.
Answer 5: an argument about the biggest size of a "physical container" (whatever that is).
Does it answer the question? No.Is it even technically sound? That depends on the definition of a "physical container", which I cannot find anywhere ("physical container" yields 70k results on Google, 'C++ "physical container"' 2k, nothing that answers it).
If it just means "container", then the argument is broken -- the maximum size (in allocation units) is half of the *address space*, and the physical amount of RAM has nothing to do with anything.
More recently we can go back to the QSerialPort discussions happening on this list not all that long ago. The student level code examples trying to do all of the I/O in the main event loop with the buffer growing and growing in size.
Answer 6: an opinion wrt. the quality of some examples around QSerialPort. Does it answer the question? No.
===== What is, when I ignore the ready read? Has the internal buffer a max size? Because at the moment I have a memory leak and maybe it comes from that? ===== They only get to use up to half of 32-bit system RAM before the wheels come off the cart. Since it was serial comm, in theory the device could stop sending for a bit, allowing them to catch up, but not if they've already maxed out the buffer and crashed. This horrible student design could have ran even longer, hoping the sender got tired long enough for them to catch up.
Answer 7: some kind of merge of the previous two answers. Does it answer the original question? No.
I quick banged this out using CodeLite on my KDE Neon desktop. Only have
a few more minutes to myself before I have to begin work this Sunday
morning. I also did not go digging through the Qt source code. Just
basing this on your previous comment that "the size definitely fits in
int." Could be headed down rabbit hole but given Qt 6 is in
planning/dev, size should no longer "just be an int."
#include <stdio.h>
#include <limits.h>
#include <stdint.h>
#include <sys/sysinfo.h>
int main(int argc, char **argv)
{
struct sysinfo my_sysinfo;
printf("hello world\n");
printf("INT_MAX: %d\n", INT_MAX);
printf("UINT_MAX: %u\n\n", UINT_MAX);
printf("INT32_MAX: %d\n", INT32_MAX);
printf("UINT32_MAX: %ul\n\n", UINT32_MAX);
printf("INT64_MAX: %ld\n", INT64_MAX);
printf("UINT64_MAX: %llu\n\n", UINT64_MAX);
sysinfo( &my_sysinfo);
printf("totalram: %lu totalswap: %lu mem_unit: %u\n\n",
my_sysinfo.totalram, my_sysinfo.totalswap, my_sysinfo.mem_unit);
return 0;
}
=====
hello world
INT_MAX: 2147483647
UINT_MAX: 4294967295
INT32_MAX: 2147483647
UINT32_MAX: 4294967295l
INT64_MAX: 9223372036854775807
UINT64_MAX: 18446744073709551615
totalram: 25144201216 totalswap: 84807774208 mem_unit: 1
Press ENTER to continue...
=====
Answer 7: some information about your system and some anecdote about your Sunday.
Does it answer the question? No.
Even with 24Gig of RAM in the box I can't get a Qt container larger than INT_MAX
Answer 8: an observation about the limitations of Qt containers. Does it answer the question? No.
I ass-u-me qsizetype is going to fix the initial problem by compiling to a platform specific integer size. It needs to take it a step further and become a platform specific unsigned size, especially for QByteArray. Why?
Answer 9: an observation regarding the fact that qsizetype would allow to lift this limitation, but it needs also to become an _unsigned_ type.
Does it answer the question? No. But it ups the ante with another question.
I haven't looked under the hood in a bit, but, just how many places do the tools/classes for some of the script kiddie favorites like XML and JSON have to bring in an entire file, then parse it? Unless that is somehow now parsing as it reads instead of requiring a hale and hole object, you still have a significant point of sporadic failure. Some files parse, others make it fall over.
Answer 10: an observation regarding parsing JSON/XML. Does it answer the first question? No. Does it answer the second question? No.
Right now it is almost impossible to obtain, at a cost effective price, human-life-at-risk quality RAM modules smaller than 1Gig. We "could" get a 512Meg module but it cost more. The hardware designers left room and power for an even larger module because by the time we get close to production it is entirely possible the cheaper multi-year production contract will be for the 2Gig modules. The vendor has already let us know this as they are trying to spin down the older lines. I have to believe that within 2 years the smallest module vendors will be willing to provide a 7-10 year production contract on will be 4Gig and they will be trying to push device manufacturers to abandon 32-bit targets even though the use can't justify 64-bit. The power consumption is what has to improve. Many medical devices have to run 7-10 days on a single battery pack. I'm actually kind of surprised Inogen has been able to get away with only 5 hours for a double battery pack but it probably has to do with the fact it can be plugged in to charge while running. https://www.inogen.com/pdf/96-06728-00-01-B-English-Only-Final-WEB.pdf ===== The battery will power the Inogen One® G4 withoutconnection to an external power source.When fully charged,a single battery will provide up to 2.7 hours of operation;a double battery will provide up to 5 hours of operation.The battery recharges when properly installed in the Inogen One® G4 and the concentrator is connected to AC or DC power.Recharging time is up to 3 hours for a single battery and 5 hours for a double battery.See information in the “Battery Care and Maintenance”section. ===== People are supposed to sleep for 8 hours.
Answer 11: a comment regarding obtaining RAM modules, and power consumption of a random hardware (?) product.
Does it answer the first question? No. Does it answer the second question? No. ==Result: please, let's stop this charade. This is *clearly* trolling, at this point, and a waste of everyone's time.
I'm officially calling for moderation on this person. Regards, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
