[Interest] Interest Digest, Vol 92, Issue 8

[Roland Hughes]

On 5/7/2019 12:14 PM, Thiago Macieira wrote:
> On Tuesday, 7 May 2019 05:13:33 PDT Ola Røer Thorsen wrote:
>> lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira <thiago.macieira at intel.com
>>
>>> 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?
>> We build our code using gcc with the options "-Wall -Wextra -Werror" and
>> this leads us to have to use static_cast for example when comparing int and
>> unsigned int (or std::size_t). A mix of using std::array, std::string and
>> QVector/QByteArray often gives a few extra static casts, not that it
>> bothers me too much.
> Well, that's your problem: mixing the APIs. The committee has recognised that
> it should have used signed types, but it can't change now.
>
> 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.

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.

I haven't dug under the hood but I wonder if this impacts memory mapping of files. Maybe not if there is no container.

uchar * dl_map = m_libraryFile.map(0, m_libraryFile.size());

====
developer at developer-U18-64-VirtualBox:~$ ./test_sizes
     short int: 2
           int: 4
      long int: 8
long long int: 8
        size_t: 8
         void*: 8
  unsigned int: 4
      uint32_t: 4
      uint64_t: 8
        void *: 8
unsigned long: 8
  uint32_t max: 4294967295
      uint max: 4294967295
  uint64_t max: 18446744073709551615
====
developer at developer-U18-64-VirtualBox:~$ cat test_sizes.c
#include <stdio.h>
#include <limits.h>
#include <stdint.h>

int main() {
         printf( "    short int: %zd\n" , sizeof(short int) ) ;
         printf( "          int: %zd\n" , sizeof(int) ) ;
         printf( "     long int: %zd\n", sizeof(long int) ) ;

         printf( "long long int: %zd\n", sizeof(long long int) ) ;
         printf( "       size_t: %zd\n", sizeof(size_t) ) ;
         printf( "        void*: %zd\n", sizeof(void *) ) ;
         printf( " unsigned int: %zd\n", sizeof(unsigned int));
         printf( "     uint32_t: %zd\n", sizeof(uint32_t));
         printf( "     uint64_t: %zd\n", sizeof(uint64_t));
         printf( "       void *: %zd\n", sizeof(void *));

         printf( "unsigned long: %zd\n", sizeof(unsigned long) );

         printf( " uint32_t max: %u\n", UINT32_MAX);
         printf( "     uint max: %u\n", UINT_MAX);
         printf( " uint64_t max: %lu\n", UINT64_MAX);

         return 0;
}developer at developer-U18-64-VirtualBox:~$
=====
developer at developer-U18-64-VirtualBox:~$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
  
=====

The ptrdiff_t comment earlier is a red herring.

https://en.cppreference.com/w/cpp/types/ptrdiff_t

typedef /*implementation-defined*/ ptrdiff_t;

=====

The static cast issue is a problem in the embedded device world. Well, 
it is an annoyance in the embedded device world. It's a documentation 
and defending your honor nightmare in regulated device world such as 
medical devices. Probably nuke systems as well.

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


-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190507/94884fb5/attachment.html>