[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
> 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.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