[Interest] Interest Digest, Vol 92, Issue 5

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Mon May 6 12:45:34 CEST 2019

Il 05/05/19 15:07, Roland Hughes ha scritto:
> 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?

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

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.

Giuseppe D'Angelo | giuseppe.dangelo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190506/4cacbea5/attachment.bin>

More information about the Interest mailing list