Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #69929 > unrolled thread

[QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding

Back to article view | Back to comp.lang.c++

Contents

  [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-20 19:55 +0100
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-20 20:12 +0100
      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-20 22:33 -0800
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-20 20:22 +0100
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-20 19:34 +0000
      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 00:54 +0100
        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-20 16:27 -0800
        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Manfred <invalid@add.invalid> - 2019-11-21 01:48 +0100
          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 04:09 +0100
        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-20 17:44 -0800
          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 04:14 +0100
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-20 22:03 +0100
      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 01:00 +0100
        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-21 13:22 +0100
          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-21 11:30 -0800
            Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-21 22:54 +0100
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-20 23:28 +0200
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-20 15:48 -0800
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Reinhardt Behm <rbehm@hushmail.com> - 2019-11-21 10:33 +0800
      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-21 13:25 +0100
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-20 22:32 -0800
      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-20 22:43 -0800
        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 12:53 +0100
          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-21 18:20 +0200
            Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 18:07 +0100
            Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-21 17:34 +0000
            Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Christian Gollwitzer <auriocus@gmx.de> - 2019-11-22 07:26 +0100
              Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-22 00:37 -0800
                Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 10:10 +0100
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 02:23 -0800
                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 12:38 +0100
                      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Manfred <noname@add.invalid> - 2019-11-22 17:13 +0100
                        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 18:48 +0100
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 10:49 -0500
                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 10:52 -0500
                      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:51 -0800
                Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 11:20 +0100
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-22 10:00 -0800
              Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 09:37 +0100
                Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 01:37 -0800
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 11:40 +0100
                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 04:55 -0800
                      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 15:18 +0100
                        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 07:23 -0800
                          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 16:34 +0100
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding scott@slp53.sl.home (Scott Lurndal) - 2019-11-22 15:16 +0000
                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-23 05:11 -0800
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 10:56 -0500
                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-23 07:03 -0800
                Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 11:31 +0100
                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 12:23 +0100
                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 13:14 +0100
                      Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 15:04 +0100
                        Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 19:35 +0100
                          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 14:11 -0500
                            Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 00:25 +0100
                              Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 23:56 -0500
                                Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 11:12 +0100
                                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-23 14:51 +0200
                                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-25 11:45 -0500
                          Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-22 22:04 -0800
                            Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 11:26 +0100
                              Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-23 12:27 -0800
                                Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-24 00:54 +0100
                                  Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-23 17:06 -0800
                                    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-24 12:10 +0100
    Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 13:21 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#69929 — [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding

I am trying to create a statically linked library in the 
said IDE.
I would not want to include many QT features for now
so, what is the STANDARD C++ way to get
unsigned 8 bits integer type ?

I fear that unsigned char is system dependent (and even if 
there are "wider" explicitely supported types, no plain char 
type seems to warranty to be 8 bits wide).

The solution of creating an unnamed structure with a "bit 
field like
struct {unsigned Pixel : 8} Mask;
gives me a warning like : 3 byte PADDING used to align the 
struct Mask.

Now I don't know whether this padding would exist also in 
ARRAY dynamic allocation (I'm not speaking for just the 
first address of the array, but for EVERY SINGLE ITEM in it, 
wasting as much as 3 times the space required !)

How to get rid of such alignment feature ?

in Visual Studio there were align / pad directives, but here 
on QT I dunno anything.

I don't care a lot about fastness of access, but need a true 
compact byte array (QT has its own, but I will need to 
communicate with a Gambas program using the static library, 
so I'd be not happy to interface QT internals with Gambas, 
I'd prefer a standard C++ types-based solution).

long ago CHAR was 8 bit wide, but now it seems to be 
platform dependent, and more often "a word" wide.

QT has its explicitely sized integers (even if no 8-bit sized)

TY


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [next] | [standalone]

#69930

Il 20/11/19 19:55, Soviet_Mario ha scritto:

Uhm, from some search, it seems that a "pragma pack" exist.
I still have to read it, though


> 
> I am trying to create a statically linked library in the 
> said IDE.
> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?
> 
> I fear that unsigned char is system dependent (and even if 
> there are "wider" explicitely supported types, no plain char 
> type seems to warranty to be 8 bits wide).
> 
> The solution of creating an unnamed structure with a "bit 
> field like
> struct {unsigned Pixel : 8} Mask;
> gives me a warning like : 3 byte PADDING used to align the 
> struct Mask.
> 
> Now I don't know whether this padding would exist also in 
> ARRAY dynamic allocation (I'm not speaking for just the 
> first address of the array, but for EVERY SINGLE ITEM in it, 
> wasting as much as 3 times the space required !)
> 
> How to get rid of such alignment feature ?
> 
> in Visual Studio there were align / pad directives, but here 
> on QT I dunno anything.
> 
> I don't care a lot about fastness of access, but need a true 
> compact byte array (QT has its own, but I will need to 
> communicate with a Gambas program using the static library, 
> so I'd be not happy to interface QT internals with Gambas, 
> I'd prefer a standard C++ types-based solution).
> 
> long ago CHAR was 8 bit wide, but now it seems to be 
> platform dependent, and more often "a word" wide.
> 
> QT has its explicitely sized integers (even if no 8-bit sized)
> 
> TY
> 
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#69948

Soviet_Mario <SovietMario@CCCP.MIR> writes:
> Il 20/11/19 19:55, Soviet_Mario ha scritto:
> Uhm, from some search, it seems that a "pragma pack" exist.
> I still have to read it, though

pragma pack is a common extension, but it's non-standard.  If you're
worried enough about portability that you're unwilling to assume
CHAR_BIT==8, you probably don't want to depend on extensions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#69932

Il 20/11/19 19:55, Soviet_Mario ha scritto:



this

#pragma pack(push,1) // pushes the current alignment setting 
on an internal stack and then optionally sets the new alignment.
     typedef struct clsByte
     {
         union
         {
             unsigned PixelMask : 8;
         };
     } clsByte;
#pragma pack(pop) // restores former default value

seems to have suppressed the warning

A further question (general)

as I am accessing BYTES (not multibyte object), apart from 
performance issues, do you think there could be a 
portability issue ?
I am thinking that addressing strict bytes should require 
accessing EVERY non aligned address in general (string 
operations on ascii chars and odd length would be impossible 
otherwise).

Is it correct ?

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#69933

On Wed, 2019-11-20, Soviet_Mario wrote:
>
> I am trying to create a statically linked library in the 
> said IDE.

The IDE doesn't matter; the Qt libraries do matter.

> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?

uint8_t, just like in C.  Or, I guess it's really std::uint8_t.

> I fear that unsigned char is system dependent (and even if 
> there are "wider" explicitely supported types, no plain char 
> type seems to warranty to be 8 bits wide).
...
> long ago CHAR was 8 bit wide, but now it seems to be 
> platform dependent, and more often "a word" wide.

No; a char is rarely more than 8 bits nowadays.  You may be thinking
of wchar_t, but that's something different.

> QT has its explicitely sized integers (even if no 8-bit sized)

Qt has its own versions of most things ... are you sure you need it?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#69938

Il 20/11/19 20:34, Jorgen Grahn ha scritto:
> On Wed, 2019-11-20, Soviet_Mario wrote:
>>
>> I am trying to create a statically linked library in the
>> said IDE.
> 
> The IDE doesn't matter; the Qt libraries do matter.
> 
>> I would not want to include many QT features for now
>> so, what is the STANDARD C++ way to get
>> unsigned 8 bits integer type ?
> 
> uint8_t, just like in C.  Or, I guess it's really std::uint8_t.

I opened the headers, i.g. sys/types.h and stdint.h
and they finally stem from a typedef that turns out to be a 
"delusional" unsigned char.
I write delusional as I still do not have found a strict 
warranty that a char is really 8 bit wide

> 
>> I fear that unsigned char is system dependent (and even if
>> there are "wider" explicitely supported types, no plain char
>> type seems to warranty to be 8 bits wide).
> ...
>> long ago CHAR was 8 bit wide, but now it seems to be
>> platform dependent, and more often "a word" wide.
> 
> No; a char is rarely more than 8 bits nowadays.  You may be thinking
> of wchar_t, but that's something different.

ok, note taken. But is it a warranty or a very common guess ?

> 
>> QT has its explicitely sized integers (even if no 8-bit sized)
> 
> Qt has its own versions of most things ... are you sure you need it?

Yes it has many types redecorated its own way.

But as I wrote I'm not much confident on them on one side 
(not on themselves, on my skills obv.) and I often cannot 
even guess what they could be like from "outside".
With gambas I just got to work with integral types, even 
"strings" are still very difficult to me
So I'd feel better the less "wrappers" around types are put.

Now I'm exploring the solution with a struct containing only 
a 8 bit field, and the #pragma pack

> 
> /Jorgen
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#69939

On Thursday, 21 November 2019 01:54:39 UTC+2, Soviet_Mario  wrote:
> Il 20/11/19 20:34, Jorgen Grahn ha scritto:
> > 
> > No; a char is rarely more than 8 bits nowadays.  You may be thinking
> > of wchar_t, but that's something different.
> 
> ok, note taken. But is it a warranty or a very common guess ?

Use std::uint8_t from <cstdint> or uint8_t from <stdint.h> anyway
just to document what you do. Both must be only present when the
platform supports 8 bit unsigned integers. I don't know existence 
of any platforms with conforming C++ compilers that do not support
those or where those are not unsigned char but so what?

> 
> Now I'm exploring the solution with a struct containing only 
> a 8 bit field, and the #pragma pack

An uint8_t directly or wrapped into struct feels better.
Your unsigned bitfield in anonymous union in packed struct 
is possibly not very well tested / profiled in all situations on
all compilers and so may have odd differences of performance
or the like.

[toc] | [prev] | [next] | [standalone]

#69940

On 11/21/19 12:54 AM, Soviet_Mario wrote:
>> uint8_t, just like in C.  Or, I guess it's really std::uint8_t.
> 
> I opened the headers, i.g. sys/types.h and stdint.h
> and they finally stem from a typedef that turns out to be a "delusional" 
> unsigned char.
> I write delusional as I still do not have found a strict warranty that a 
> char is really 8 bit wide

It's not delusional, it's how it works.
You opened some standard header of your implementation, and since in 
your implementation a byte is an unsigned char, this is the correct typedef.
If you happen to port the code to an implementation (if any) where a 
byte has a different representation, then the standard header of that 
implementation would have the corresponding definition.

This way of working is most evident with stuff like uint32_t and 
uint64_t (as many have said, most of the time uint8_t is an unsigned char).

If porting to an implementation where no byte is available, then uint8_t 
would not be defined (also said by others).

Gist of the story is, yes, uint8_t is guaranteed to be an 8-bit unsigned 
integer, as its name suggests.

[toc] | [prev] | [next] | [standalone]

#69944

Il 21/11/19 01:48, Manfred ha scritto:
> On 11/21/19 12:54 AM, Soviet_Mario wrote:
>>> uint8_t, just like in C.  Or, I guess it's really 
>>> std::uint8_t.
>>
>> I opened the headers, i.g. sys/types.h and stdint.h
>> and they finally stem from a typedef that turns out to be 
>> a "delusional" unsigned char.
>> I write delusional as I still do not have found a strict 
>> warranty that a char is really 8 bit wide
> 
> It's not delusional, it's how it works.
> You opened some standard header of your implementation, and 
> since in your implementation a byte is an unsigned char, 
> this is the correct typedef.
> If you happen to port the code to an implementation (if any) 
> where a byte has a different representation, then the 
> standard header of that implementation would have the 
> corresponding definition.
> 
> This way of working is most evident with stuff like uint32_t 
> and uint64_t (as many have said, most of the time uint8_t is 
> an unsigned char).
> 
> If porting to an implementation where no byte is available, 
> then uint8_t would not be defined (also said by others).
> 
> Gist of the story is, yes, uint8_t is guaranteed to be an 
> 8-bit unsigned integer, as its name suggests.


mmm, all changes then, as it was the warranty I was looking 
for !



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#69942

On Wednesday, November 20, 2019 at 6:54:39 PM UTC-5, Soviet_Mario wrote:
> Il 20/11/19 20:34, Jorgen Grahn ha scritto:
> > On Wed, 2019-11-20, Soviet_Mario wrote:
...
> >> I would not want to include many QT features for now
> >> so, what is the STANDARD C++ way to get
> >> unsigned 8 bits integer type ?
> > 
> > uint8_t, just like in C.  Or, I guess it's really std::uint8_t.
> 
> I opened the headers, i.g. sys/types.h and stdint.h
> and they finally stem from a typedef that turns out to be a 
> "delusional" unsigned char.
> I write delusional as I still do not have found a strict 
> warranty that a char is really 8 bit wide

You won't find it, because there is no such warranty in general. The
minimum value for CHAR_BIT is quite explicitly 8, but there is no
maximum, and it's certainly not required to be 8. Values other than 8
are rare, but not unheard of.

However, any conforming implementation of C++ for which <cstdint>
contains a typedef of uint8_t as unsigned char IS guaranteed to be one
for which unsigned char is an 8 bit type. That's not because of anything
the standard says directly about unsigned char; it's because it's not
permitted to for uint8_t to be a typedef for a type that isn't exactly 8
bits. The relevant guarantee is in the C standard, and incorporated into
the C++ standard by reference, but it is still a guarantee.

If CHAR_BIT != 8, or #ifndef UINT8_MAX, then there will be no way to
declare an 8-bit type for that implementation (except for bit-fields,
and you can't make arrays of bit-fields).

The key question the OP needs to ask himself is "What do I want my
program to do when compiled on a platform where there is no way to
declare an 8-bit type?". There's many options: failing to compile with
an explicit error message is one possibility. Depending upon what he
actually needs to do, uint_least8_t might be an acceptable alternative,
though I doubt it.

...
> >> long ago CHAR was 8 bit wide, but now it seems to be
> >> platform dependent, and more often "a word" wide.
> > 
> > No; a char is rarely more than 8 bits nowadays.  You may be thinking
> > of wchar_t, but that's something different.
> 
> ok, note taken. But is it a warranty or a very common guess ?

It's very common, not guaranteed, and there's no need to guess about it.
Just check the value of CHAR_BIT.

...
> Now I'm exploring the solution with a struct containing only 
> a 8 bit field, and the #pragma pack.

On a platform where CHAR_BIT==8, unsigned char will work. On a platform
where CHAR_BIT != 8, that approach won't work, nor will any other.

[toc] | [prev] | [next] | [standalone]

#69945

Il 21/11/19 02:44, James Kuyper ha scritto:
> On Wednesday, November 20, 2019 at 6:54:39 PM UTC-5, Soviet_Mario wrote:
>> Il 20/11/19 20:34, Jorgen Grahn ha scritto:
>>> On Wed, 2019-11-20, Soviet_Mario wrote:
> ...
>>>> I would not want to include many QT features for now
>>>> so, what is the STANDARD C++ way to get
>>>> unsigned 8 bits integer type ?
>>>
>>> uint8_t, just like in C.  Or, I guess it's really std::uint8_t.
>>
>> I opened the headers, i.g. sys/types.h and stdint.h
>> and they finally stem from a typedef that turns out to be a
>> "delusional" unsigned char.
>> I write delusional as I still do not have found a strict
>> warranty that a char is really 8 bit wide
> 
> You won't find it, because there is no such warranty in general. The
> minimum value for CHAR_BIT is quite explicitly 8, but there is no
> maximum, and it's certainly not required to be 8. Values other than 8
> are rare, but not unheard of.
> 
> However, any conforming implementation of C++ for which <cstdint>
> contains a typedef of uint8_t as unsigned char IS guaranteed to be one
> for which unsigned char is an 8 bit type. That's not because of anything
> the standard says directly about unsigned char; it's because it's not
> permitted to for uint8_t to be a typedef for a type that isn't exactly 8
> bits. The relevant guarantee is in the C standard, and incorporated into
> the C++ standard by reference, but it is still a guarantee.

very clear (and very good for me!)
tnx

> 
> If CHAR_BIT != 8, or #ifndef UINT8_MAX, then there will be no way to
> declare an 8-bit type for that implementation (except for bit-fields,
> and you can't make arrays of bit-fields).

actually I made an array of the enclosing struct of the bit 
field (which was the only member but this may not be relevant).
I noticed that the "padding warning disappeared" with the 
#pragma pack(1)
which might be a proof that the system is capable of 
addressing single bytes regardless of their alignment in memory

but all this now is unnecessary, after what you all have stated

> 
> The key question the OP needs to ask himself is "What do I want my
> program to do when compiled on a platform where there is no way to
> declare an 8-bit type?". 

none, I won't possibly port it anywhere, just run here locally

> There's many options: failing to compile with
> an explicit error message is one possibility. Depending upon what he
> actually needs to do, uint_least8_t might be an acceptable alternative,
> though I doubt it.
> 
> ...
>>>> long ago CHAR was 8 bit wide, but now it seems to be
>>>> platform dependent, and more often "a word" wide.
>>>
>>> No; a char is rarely more than 8 bits nowadays.  You may be thinking
>>> of wchar_t, but that's something different.
>>
>> ok, note taken. But is it a warranty or a very common guess ?
> 
> It's very common, not guaranteed, and there's no need to guess about it.
> Just check the value of CHAR_BIT.
> 
> ...
>> Now I'm exploring the solution with a struct containing only
>> a 8 bit field, and the #pragma pack.
> 
> On a platform where CHAR_BIT==8, unsigned char will work. On a platform
> where CHAR_BIT != 8, that approach won't work, nor will any other.

understood. So the workaround worked only because the system 
was just able to address single bytes

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#69934

On 20/11/2019 19:55, Soviet_Mario wrote:
> 
> I am trying to create a statically linked library in the said IDE.
> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?

uint8_t from <stdint.h>, or std::uint8_t from <cstdint>.

> 
> I fear that unsigned char is system dependent (and even if there are 
> "wider" explicitely supported types, no plain char type seems to 
> warranty to be 8 bits wide).
> -based solution).
> 

<snip>

> long ago CHAR was 8 bit wide, but now it seems to be platform dependent, 
> and more often "a word" wide.
> 

The size of "char" has always been platform dependent.  Whether plain 
"char" is signed or unsigned has also always been platform dependent.

On most systems, "char" is 8-bit, but the signedness varies - always 
specify it explicitly ("signed char" or "unsigned char") when it is 
relevant.  Typically you only find char bigger than 8-bit on DSP's or 
other specialist processors.

But if you stick to the standard type "uint8_t", you get exactly what 
you ask for.  (If the platform doesn't support 8-bit char, the type 
won't exist and the code won't compile.  But very little code needs to 
be /that/ portable.)

[toc] | [prev] | [next] | [standalone]

#69941

Il 20/11/19 22:03, David Brown ha scritto:
> On 20/11/2019 19:55, Soviet_Mario wrote:
>>
>> I am trying to create a statically linked library in the 
>> said IDE.
>> I would not want to include many QT features for now
>> so, what is the STANDARD C++ way to get
>> unsigned 8 bits integer type ?
> 
> uint8_t from <stdint.h>, or std::uint8_t from <cstdint>.

i inquired, and they expand to a typedef related to unsigned 
char

> 
>>
>> I fear that unsigned char is system dependent (and even if 
>> there are "wider" explicitely supported types, no plain 
>> char type seems to warranty to be 8 bits wide).
>> -based solution).
>>
> 
> <snip>
> 
>> long ago CHAR was 8 bit wide, but now it seems to be 
>> platform dependent, and more often "a word" wide.
>>
> 
> The size of "char" has always been platform dependent.  
> Whether plain "char" is signed or unsigned has also always 
> been platform dependent.
> 
> On most systems, "char" is 8-bit, but the signedness varies 
> - always specify it explicitly ("signed char" or "unsigned 
> char") when it is relevant.  Typically you only find char 
> bigger than 8-bit on DSP's or other specialist processors.
> 
> But if you stick to the standard type "uint8_t", you get 
> exactly what you ask for.  (If the platform doesn't support 
> 8-bit char, the type won't exist and the code won't 
> compile.  But very little code needs to be /that/ portable.)

uhm ... maybe. But I am trying to mirror a byte-wise mask of 
opacity/transparency from images, so I have to get two 
different pieces of programs (a front end in gambas and this 
would-be static library to speak the same language and have 
the same data layout).

To be very very tight fisted, I could even have devoted a 
SINGLE BIT to the transparency mask, but addressing would 
have become far slower. So I waste 7 bits ! but no more.

The pictures themselves are also made of bit fields, but are 
four fields 8 bit each, so exactly 32 bit / pixel and the 
packing was not necessary there (and also align issue did 
not show up).

the gambas frontend has a native type BYTE  (0-255 range) 
for the transparency mask so I have to replicate it in the 
library


> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#69953

On 21/11/2019 01:00, Soviet_Mario wrote:
> Il 20/11/19 22:03, David Brown ha scritto:
>> On 20/11/2019 19:55, Soviet_Mario wrote:
>>>
>>> I am trying to create a statically linked library in the said IDE.
>>> I would not want to include many QT features for now
>>> so, what is the STANDARD C++ way to get
>>> unsigned 8 bits integer type ?
>>
>> uint8_t from <stdint.h>, or std::uint8_t from <cstdint>.
> 
> i inquired, and they expand to a typedef related to unsigned char
> 

That is because <stdint.h> and <cstdint> (and other standard library
headers) are adapted to suit the target processor.

uint8_t is a bad example here, because (AFAIK) if a compiler supports a
type that could be used for uint8_t, then "unsigned char" is always
going to be suitable for it.  (That does not mean it is the only choice.)

Consider uint32_t.  This type is guaranteed to be 32-bit, unsigned, with
no padding bits.  If a C99/C++11 compiler has a type that can fit these
requirements (along with a matching int32_t), it /must/ provide uint32_t
and int32_t types.  But it is up to the implementation - the compiler
and the standard headers - to decide how to do that.  On one platform,
it might have "typedef unsigned int uint32_t;".  On another, it could
have "typedef unsigned long int uint32_t;".  On another, it could have
"typedef __UINT32_TYPE__ uint32_t;".  The standard headers, like
<stdint.h>, are /not/ portable - they are fixed for the given compiler
implementation.

Thus when you want a 32-bit unsigned integer, you use "uint32_t" and let
the C/C++ implementation worry about how it makes that work on this
particular target.

The fixed size types exist precisely to let you write code in a portable
way with specific requirements for the types, without having to know
details of the underlying target.



>>
>>>
>>> I fear that unsigned char is system dependent (and even if there are
>>> "wider" explicitely supported types, no plain char type seems to
>>> warranty to be 8 bits wide).
>>> -based solution).
>>>
>>
>> <snip>
>>
>>> long ago CHAR was 8 bit wide, but now it seems to be platform
>>> dependent, and more often "a word" wide.
>>>
>>
>> The size of "char" has always been platform dependent.  Whether plain
>> "char" is signed or unsigned has also always been platform dependent.
>>
>> On most systems, "char" is 8-bit, but the signedness varies - always
>> specify it explicitly ("signed char" or "unsigned char") when it is
>> relevant.  Typically you only find char bigger than 8-bit on DSP's or
>> other specialist processors.
>>
>> But if you stick to the standard type "uint8_t", you get exactly what
>> you ask for.  (If the platform doesn't support 8-bit char, the type
>> won't exist and the code won't compile.  But very little code needs to
>> be /that/ portable.)
> 
> uhm ... maybe. But I am trying to mirror a byte-wise mask of
> opacity/transparency from images, so I have to get two different pieces
> of programs (a front end in gambas and this would-be static library to
> speak the same language and have the same data layout).

Use uint8_t.

> 
> To be very very tight fisted, I could even have devoted a SINGLE BIT to
> the transparency mask, but addressing would have become far slower. So I
> waste 7 bits ! but no more.

uint8_t is always 8 bits.  No more, no less.

> 
> The pictures themselves are also made of bit fields, but are four fields
> 8 bit each, so exactly 32 bit / pixel and the packing was not necessary
> there (and also align issue did not show up).
> 
> the gambas frontend has a native type BYTE  (0-255 range) for the
> transparency mask so I have to replicate it in the library
> 

C and C++ have an equivalent type.  It is called "uint8_t".

[toc] | [prev] | [next] | [standalone]

#69963

David Brown <david.brown@hesbynett.no> writes:
[...]
> uint8_t is always 8 bits.  No more, no less.
[...]

Yes.  Expanding on that, uint8_t is always 8 bits *if it exists*.

(And in the real world, it almost always exists.  You're far more
likely to encounter a very old implementation that doesn't support
<stdint.h> or <cstdint> than to encounter one that does have those
headers but has CHAR_BIT>8.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#69964

On 21/11/2019 20:30, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> uint8_t is always 8 bits.  No more, no less.
> [...]
> 
> Yes.  Expanding on that, uint8_t is always 8 bits *if it exists*.
> 
> (And in the real world, it almost always exists.  You're far more
> likely to encounter a very old implementation that doesn't support
> <stdint.h> or <cstdint> than to encounter one that does have those
> headers but has CHAR_BIT>8.)
> 

That is certainly true if by "in the real world" you mean "platforms 
that support QT" :-)

I've worked with a couple of devices that have 16-bit CHAR, and been 
indirectly connected with a project using one with 32-bit CHAR.  These 
were DSP devices, but are current devices, with new family members being 
added regularly.  But it is very rare that you want much software that 
will be portable between these sorts of chips and other more "normal" 
processors.

Balancing that, I have a few compilers that I still have occasion to use 
that don't support <stdint.h> (or C++, for that matter).

[toc] | [prev] | [next] | [standalone]

#69935

On 20.11.2019 20:55, Soviet_Mario wrote:
>
> I am trying to create a statically linked library in the said IDE.
> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?

Why do you need an exactly 8-bit type? And how this is related to QT or 
static linking, or to an IDE?

In general, if you need an unsigned 8-bit type, use std::uint8_t.

[toc] | [prev] | [next] | [standalone]

#69937

On Wednesday, November 20, 2019 at 1:55:45 PM UTC-5, Soviet_Mario wrote:
> I am trying to create a statically linked library in the 
> said IDE.
> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?

You should use uint8_t, a typedef declared in <cstdint>. The meaning of
this type is specified in the C standard, and incorporated into the C++
standard only by reference. The type is optional, you can check whether
or not UINT8_MAX is #defined to determine whether or not the type is
supported.  As a practical matter, an implementation will fail to
support uint8_t only when compiling code to run on a platform that where
an 8-bit data type cannot be implemented, at least not efficiently.

You can also check CHAR_BIT, a macro #defined in <climits>. If
CHAR_BIT==8, then unsigned char can also be used, and uint8_t will
almost certainly be a typedef for unsigned char. As with uint8_t, if
CHAR_BIT!=8, then you an safely assume that the target platform is one
where an 8-bit type cannot be efficiently supported.

> I fear that unsigned char is system dependent (and even if 
> there are "wider" explicitely supported types, no plain char 
> type seems to warranty to be 8 bits wide).

Correct.

> The solution of creating an unnamed structure with a "bit 
> field like
> struct {unsigned Pixel : 8} Mask;
> gives me a warning like : 3 byte PADDING used to align the 
> struct Mask.

That approach will not work. The size of that struct is guaranteed to
be a positive integer number of bytes. On any platform where unsigned
char is NOT an 8-bit type, that struct is guaranteed to have a size
bigger than 8 bits. Even on a platform where CHAR_BIT==8, that struct
might be larger than 8 bits.

...
> long ago CHAR was 8 bit wide, but now it seems to be 
> platform dependent, and more often "a word" wide.

There is no CHAR type in C. There is a char type - C++ is a case-
sensitive language, so that distinction is important. The number of bits
in a char object has always been platform dependent.

[toc] | [prev] | [next] | [standalone]

#69943

On 11/21/19 2:55 AM, Soviet_Mario wrote:
> 
> I am trying to create a statically linked library in the said IDE.
> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?
> 
> I fear that unsigned char is system dependent (and even if there are 
> "wider" explicitely supported types, no plain char type seems to 
> warranty to be 8 bits wide).
> 
> The solution of creating an unnamed structure with a "bit field like
> struct {unsigned Pixel : 8} Mask;
> gives me a warning like : 3 byte PADDING used to align the struct Mask.
> 
> Now I don't know whether this padding would exist also in ARRAY dynamic 
> allocation (I'm not speaking for just the first address of the array, 
> but for EVERY SINGLE ITEM in it, wasting as much as 3 times the space 
> required !)
> 
> How to get rid of such alignment feature ?
> 
> in Visual Studio there were align / pad directives, but here on QT I 
> dunno anything.
> 
> I don't care a lot about fastness of access, but need a true compact 
> byte array (QT has its own, but I will need to communicate with a Gambas 
> program using the static library, so I'd be not happy to interface QT 
> internals with Gambas, I'd prefer a standard C++ types-based solution).
> 
> long ago CHAR was 8 bit wide, but now it seems to be platform dependent, 
> and more often "a word" wide.
> 
> QT has its explicitely sized integers (even if no 8-bit sized)

Of  course it has: Q_UINT8

The standard way would be (u)int8_t, if it is defined in your compiler.

[toc] | [prev] | [next] | [standalone]

#69952

On 21/11/2019 03:33, Reinhardt Behm wrote:
> On 11/21/19 2:55 AM, Soviet_Mario wrote:
>>
>> I am trying to create a statically linked library in the said IDE.
>> I would not want to include many QT features for now
>> so, what is the STANDARD C++ way to get
>> unsigned 8 bits integer type ?
>>
>> I fear that unsigned char is system dependent (and even if there are
>> "wider" explicitely supported types, no plain char type seems to
>> warranty to be 8 bits wide).
>>
>> The solution of creating an unnamed structure with a "bit field like
>> struct {unsigned Pixel : 8} Mask;
>> gives me a warning like : 3 byte PADDING used to align the struct Mask.
>>
>> Now I don't know whether this padding would exist also in ARRAY
>> dynamic allocation (I'm not speaking for just the first address of the
>> array, but for EVERY SINGLE ITEM in it, wasting as much as 3 times the
>> space required !)
>>
>> How to get rid of such alignment feature ?
>>
>> in Visual Studio there were align / pad directives, but here on QT I
>> dunno anything.
>>
>> I don't care a lot about fastness of access, but need a true compact
>> byte array (QT has its own, but I will need to communicate with a
>> Gambas program using the static library, so I'd be not happy to
>> interface QT internals with Gambas, I'd prefer a standard C++
>> types-based solution).
>>
>> long ago CHAR was 8 bit wide, but now it seems to be platform
>> dependent, and more often "a word" wide.
>>
>> QT has its explicitely sized integers (even if no 8-bit sized)
> 
> Of  course it has: Q_UINT8
> 
> The standard way would be (u)int8_t, if it is defined in your compiler.
> 

And if it is not defined by the compiler, there is no Q_UINT8 type
either.  In fact, there is no QT for the target.

(The exception here would be a very old version of a poor quality
compiler that does not support C++11 or C99 - then you might be missing
<stdint.h> and <cstdint>.)

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web