[Interest] Interest Digest, Vol 92, Issue 5
roland at logikalsolutions.com
Sun May 5 15:07:03 CEST 2019
On 5/5/19 5:00 AM, interest-request at 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?
Virtually every English speaking embedded system shop uses the Barr
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.
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
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__
/* 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
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.
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.
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.
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."
int main(int argc, char **argv)
struct sysinfo my_sysinfo;
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);
printf("totalram: %lu totalswap: %lu mem_unit: %u\n\n",
my_sysinfo.totalram, my_sysinfo.totalswap, my_sysinfo.mem_unit);
totalram: 25144201216 totalswap: 84807774208 mem_unit: 1
Press ENTER to continue...
Even with 24Gig of RAM in the box I can't get a Qt container larger than
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.
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.
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.
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.
Roland Hughes, President
More information about the Interest