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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#69947

Soviet_Mario <SovietMario@CCCP.MIR> writes:
> 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 ?

If uint8_t exists, then both it and unsigned char are unsigned 8-bit
integer types (and very likely uint8_t is an alias for unsigned char).
Using uint8_t makes it more explicit that you want an unsigned 8-bit
integer type.

If uint8_t doesn't exist, then CHAR_BIT > 8 and there is no 8-bit
integer type.  You're unlikely to encounter such an implementation
(I've only heard of very old systems and DSPs) -- and I'd be
astonished if such a system were able to support Qt.

(There's probably some wiggle room there.  An implementation with
CHAR_BIT==8 with signed char using a representation other than
2's-complement won't define int8_t and, IIRC, therefore shouldn't define
uint8_t -- but such implementations are, I think, even rarer.)

> 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 three char types are CHAR_BIT bits, or 1 byte.

Your best bet is probably to use uint8_t, which guarantees that your
code won't compile if the implementation doesn't meet its requirements.

[...]

-- 
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]

#69949

Keith Thompson <kst-u@mib.org> writes:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>> 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 ?
>
> If uint8_t exists, then both it and unsigned char are unsigned 8-bit
> integer types (and very likely uint8_t is an alias for unsigned char).
> Using uint8_t makes it more explicit that you want an unsigned 8-bit
> integer type.
>
> If uint8_t doesn't exist, then CHAR_BIT > 8 and there is no 8-bit
> integer type.  You're unlikely to encounter such an implementation
> (I've only heard of very old systems and DSPs) -- and I'd be
> astonished if such a system were able to support Qt.
[...]

I'm curious about something.  Do you have a realistic expectation that
your code might need to work under an implementation with CHAR_BIT > 8?
Do you have such a target system in mind?

C++ with the assumption that CHAR_BIT==8 is realistically at least 99%
as portable as C++ without that assumption -- and far more portable than
C++ with the assumption that Qt is available.

-- 
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]

#69951

Il 21/11/19 07:43, Keith Thompson ha scritto:
> Keith Thompson <kst-u@mib.org> writes:
>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>> 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 ?
>>
>> If uint8_t exists, then both it and unsigned char are unsigned 8-bit
>> integer types (and very likely uint8_t is an alias for unsigned char).
>> Using uint8_t makes it more explicit that you want an unsigned 8-bit
>> integer type.
>>
>> If uint8_t doesn't exist, then CHAR_BIT > 8 and there is no 8-bit
>> integer type.  You're unlikely to encounter such an implementation
>> (I've only heard of very old systems and DSPs) -- and I'd be
>> astonished if such a system were able to support Qt.
> [...]
> 
> I'm curious about something.  Do you have a realistic expectation that
> your code might need to work under an implementation with CHAR_BIT > 8?

no, not at all.
My only requirement is that the plain native type BYTE used 
in gambas code that calls the C++ static library and that 
expects a 8-bit wide unsigned integral, find its matching 
type in the C++ code, as they need to share bitmaps and 
transparency maps.
The bitmaps use 32-bit packed colors+alpha channel, so I was 
assuming no difficulty in exchange.
The transparency mask (due to blend different images 
pattern-wise) theoretically would need just ONE BIT (not 
byte, bit) per pixel, but this would have made much more 
complex (and slow) the single pixel addressing and even 
worse calculation in gambas who does not have a good support 
for single bit R/W
so I decided to waste some space and to use an addressable 
unit of 8 bits for a boolean value

> Do you have such a target system in mind?

No, and I wont' even try to figure out. I need the program 
to work in just two machines (and AMD 10 y old and an INTEL 
1 month old), both with linux.

My only problem is to get the GUI client (gambas) to be able 
to call consistently the C++ static lib

I still have not decided whether to exchange big bitmap-like 
rectangular arrays directly via pointers or via memory files.
I have to assess if and how the FILE type for gambas is seen 
outside ...


> 
> C++ with the assumption that CHAR_BIT==8 is realistically at least 99%
> as portable as C++ without that assumption -- and far more portable than
> C++ with the assumption that Qt is available.

I have put QT on every distro in use, but I hope that 
choosing the static library solution would produce a binary 
with all the needed QT essentials hard wired in it and no 
further dependencies (just a guess, all to be verified).

I'm moving just the first steps

Initially I was writing all in gambas (which is very good 
for GUI), but I got stuck, its object pattern is too 
different from C/C++ representation and regularly when I 
lose control of data representation, I tend to resort to C++ 
way of design it, which is hugely more flexible and precise.
Then the problem of mixing code arises, though :\ :\

> 


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

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

#69958

On 21.11.2019 13:53, Soviet_Mario wrote:
> Il 21/11/19 07:43, Keith Thompson ha scritto:
>>
>> I'm curious about something.  Do you have a realistic expectation that
>> your code might need to work under an implementation with CHAR_BIT > 8?
>
> no, not at all.

Good. I suspect that without lots of porting and testing efforts none of 
these software pieces would work with CHAR_BIT>8 - neither gambas, 
neither QT and neither your code.

> My only requirement is that the plain native type BYTE used in gambas
> code that calls the C++ static library and that expects a 8-bit wide
> unsigned integral, find its matching type in the C++ code, as they need
> to share bitmaps and transparency maps.

This is easy, use unsigned char or std::uint8_t.

> The bitmaps use 32-bit packed colors+alpha channel, so I was assuming no
> difficulty in exchange.

This is more tricky because the size of int or long varies much more 
than char. For example, long is 32 bits in 64-bit MSVC and 64 bits with 
64-bit gcc on Linux.

However, for your purposes std::uint32_t should work fine.

> The transparency mask (due to blend different images pattern-wise)
> theoretically would need just ONE BIT (not byte, bit) per pixel, but
> this would have made much more complex (and slow) the single pixel
> addressing and even worse calculation in gambas who does not have a good
> support for single bit R/W
> so I decided to waste some space and to use an addressable unit of 8
> bits for a boolean value

This is a common choice, ok.

> I have put QT on every distro in use, but I hope that choosing the
> static library solution would produce a binary with all the needed QT
> essentials hard wired in it and no further dependencies (just a guess,
> all to be verified).

Qt is mostly a GUI library as far as I have understood. Of course it has 
all bells and whistles like threading support and datetime library and 
whatever, but these things are nowadays also present in standard C++. So 
if you are writing some back-end library with no GUI interface involved, 
you actually should not need Qt at all.

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

#69959

Il 21/11/19 17:20, Paavo Helde ha scritto:
> On 21.11.2019 13:53, Soviet_Mario wrote:

CUT

> 
> Qt is mostly a GUI library as far as I have understood. Of 
> course it has all bells and whistles like threading support 
> and datetime library and whatever, but these things are 
> nowadays also present in standard C++. So if you are writing 
> some back-end library with no GUI interface involved, you 
> actually should not need Qt at all.
> 
> 

uhm ... this might sound silly ... but I had not thought a 
lot about this choice. And actually I find it a darn good 
advice.
I am using an elephant to tow a feather :\
I used it without much thought, but now that you said it, 
CodeBlocks would be more than enough.
Ciao !



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

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

#69961

On 21/11/2019 16:20, Paavo Helde wrote:
> On 21.11.2019 13:53, Soviet_Mario wrote:
>> I have put QT on every distro in use, but I hope that choosing the
>> static library solution would produce a binary with all the needed QT
>> essentials hard wired in it and no further dependencies (just a guess,
>> all to be verified).
> 
> Qt is mostly a GUI library as far as I have understood. Of course it has all bells and whistles like threading support and datetime library and whatever, but these things are nowadays also present in standard C++. So if you are writing some back-end library with no GUI interface involved, you actually should not need Qt at all.

Qt has too much legacy cruft: QVector? LOL. My alternative, neoGFX, will ultimately win out as I have the distinct advantage of being able to support modern C++ as I have no legacy user-base to worry about.

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

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

#69966

Am 21.11.19 um 17:20 schrieb Paavo Helde:
> On 21.11.2019 13:53, Soviet_Mario wrote: 
>> My only requirement is that the plain native type BYTE used in gambas
>> code that calls the C++ static library and that expects a 8-bit wide
>> unsigned integral, find its matching type in the C++ code, as they need
>> to share bitmaps and transparency maps.
> 
> This is easy, use unsigned char or std::uint8_t.
> 
>> The bitmaps use 32-bit packed colors+alpha channel, so I was assuming no
>> difficulty in exchange.
> 
> This is more tricky because the size of int or long varies much more 
> than char. For example, long is 32 bits in 64-bit MSVC and 64 bits with 
> 64-bit gcc on Linux.
> 
> However, for your purposes std::uint32_t should work fine.

Why not

#pragma pack(1)
struct pixel {
	uint8_t red, green, blue, alpha;
}

? That would make more sense to me than uint32_t and bit-twiddling to 
get the channel values.

Christian

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

#69968

Christian Gollwitzer <auriocus@gmx.de> writes:
> Am 21.11.19 um 17:20 schrieb Paavo Helde:
[...]
>> However, for your purposes std::uint32_t should work fine.
>
> Why not
>
> #pragma pack(1)
> struct pixel {
> 	uint8_t red, green, blue, alpha;
> }
>
> ? That would make more sense to me than uint32_t and bit-twiddling to 
> get the channel values.

Because #pragma pack is non-standard?

If you only care about implementations that support it as an extension,
that's fine, but the OP seemed very concerned about portability.

An array of uint8_t could also work:

    typedef uint8_t pixel[4];
    enum { red, green, blue, alpha };

Or an array wrapped in a struct to allow assignment.  (An array of 4
uint8_t elements is guaranteed to be 32 bits, but a struct containing
such an array is not -- but it's a nearly safe assumption that there
will be no padding between the elements or at the end.)

-- 
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]

#69970

On 22/11/2019 09:37, Keith Thompson wrote:
> Christian Gollwitzer <auriocus@gmx.de> writes:
>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
> [...]
>>> However, for your purposes std::uint32_t should work fine.
>>
>> Why not
>>
>> #pragma pack(1)
>> struct pixel {
>> 	uint8_t red, green, blue, alpha;
>> }
>>
>> ? That would make more sense to me than uint32_t and bit-twiddling to 
>> get the channel values.
> 
> Because #pragma pack is non-standard?
> 
> If you only care about implementations that support it as an extension,
> that's fine, but the OP seemed very concerned about portability.
> 
> An array of uint8_t could also work:
> 
>     typedef uint8_t pixel[4];
>     enum { red, green, blue, alpha };
> > Or an array wrapped in a struct to allow assignment.  (An array of 4
> uint8_t elements is guaranteed to be 32 bits, but a struct containing
> such an array is not -- but it's a nearly safe assumption that there
> will be no padding between the elements or at the end.)
> 

While it is true in theory that a struct can have extra padding at the
end (beyond what is needed for an array of the struct to have proper
alignment for all members), are there any compilers that have done so in
practice?

Another option is to cover all bases with a union:

typedef union {
	uint32_t combined;
	uint8_t rgba[4];
	struct {
		uint8_t red, green, blue, alpha;
	};
} pixel;

_Static_assert(sizeof(pixel) == 4, "This only works on real systems!");

(Watch out for endian issues giving different orders within these parts
- that's always a concern for portable code when matching external file
formats.)

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

#69972

On Friday, 22 November 2019 11:10:26 UTC+2, David Brown  wrote:
> On 22/11/2019 09:37, Keith Thompson wrote:
> > Christian Gollwitzer <auriocus@gmx.de> writes:
> >> Am 21.11.19 um 17:20 schrieb Paavo Helde:
> > [...]
> >>> However, for your purposes std::uint32_t should work fine.
> >>
> >> Why not
> >>
> >> #pragma pack(1)
> >> struct pixel {
> >> 	uint8_t red, green, blue, alpha;
> >> }
> >>
> >> ? That would make more sense to me than uint32_t and bit-twiddling to 
> >> get the channel values.
> > 
> > Because #pragma pack is non-standard?
> > 
> > If you only care about implementations that support it as an extension,
> > that's fine, but the OP seemed very concerned about portability.
> > 
> > An array of uint8_t could also work:
> > 
> >     typedef uint8_t pixel[4];
> >     enum { red, green, blue, alpha };
> > > Or an array wrapped in a struct to allow assignment.  (An array of 4
> > uint8_t elements is guaranteed to be 32 bits, but a struct containing
> > such an array is not -- but it's a nearly safe assumption that there
> > will be no padding between the elements or at the end.)
> > 
> 
> While it is true in theory that a struct can have extra padding at the
> end (beyond what is needed for an array of the struct to have proper
> alignment for all members), are there any compilers that have done so in
> practice?
> 
> Another option is to cover all bases with a union:
> 
> typedef union {
> 	uint32_t combined;
> 	uint8_t rgba[4];
> 	struct {
> 		uint8_t red, green, blue, alpha;
> 	};
> } pixel;
> 
> _Static_assert(sizeof(pixel) == 4, "This only works on real systems!");
> 
> (Watch out for endian issues giving different orders within these parts
> - that's always a concern for portable code when matching external file
> formats.)

It usually works in practice but is undefined behavior in C++, so Bjarne
Stroustrup and Herb Sutter suggest against it in C++ Core Guidelines.

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ru-pun

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

#69978

On 22/11/2019 11:23, Öö Tiib wrote:
> On Friday, 22 November 2019 11:10:26 UTC+2, David Brown  wrote:
>> On 22/11/2019 09:37, Keith Thompson wrote:
>>> Christian Gollwitzer <auriocus@gmx.de> writes:
>>>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
>>> [...]
>>>>> However, for your purposes std::uint32_t should work fine.
>>>>
>>>> Why not
>>>>
>>>> #pragma pack(1)
>>>> struct pixel {
>>>> 	uint8_t red, green, blue, alpha;
>>>> }
>>>>
>>>> ? That would make more sense to me than uint32_t and bit-twiddling to 
>>>> get the channel values.
>>>
>>> Because #pragma pack is non-standard?
>>>
>>> If you only care about implementations that support it as an extension,
>>> that's fine, but the OP seemed very concerned about portability.
>>>
>>> An array of uint8_t could also work:
>>>
>>>     typedef uint8_t pixel[4];
>>>     enum { red, green, blue, alpha };
>>>> Or an array wrapped in a struct to allow assignment.  (An array of 4
>>> uint8_t elements is guaranteed to be 32 bits, but a struct containing
>>> such an array is not -- but it's a nearly safe assumption that there
>>> will be no padding between the elements or at the end.)
>>>
>>
>> While it is true in theory that a struct can have extra padding at the
>> end (beyond what is needed for an array of the struct to have proper
>> alignment for all members), are there any compilers that have done so in
>> practice?
>>
>> Another option is to cover all bases with a union:
>>
>> typedef union {
>> 	uint32_t combined;
>> 	uint8_t rgba[4];
>> 	struct {
>> 		uint8_t red, green, blue, alpha;
>> 	};
>> } pixel;
>>
>> _Static_assert(sizeof(pixel) == 4, "This only works on real systems!");
>>
>> (Watch out for endian issues giving different orders within these parts
>> - that's always a concern for portable code when matching external file
>> formats.)
> 
> It usually works in practice but is undefined behavior in C++, so Bjarne
> Stroustrup and Herb Sutter suggest against it in C++ Core Guidelines.
> 
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ru-pun
> 

You are right - I was thinking in C terms, where this /is/ defined
behaviour.  For C++, you'd need to put it all in a class and make
appropriate accessor functions.  On the plus side, that would let you
make an endian-independent solution, and if it is done well the
compiler's optimiser will eliminate all overhead.

On some compilers, like gcc, the union type-punning is guaranteed to
work in C++ too.  But then the code is not portable.

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

#69994

On 11/22/2019 12:38 PM, David Brown wrote:
> On 22/11/2019 11:23, Öö Tiib wrote:
>> On Friday, 22 November 2019 11:10:26 UTC+2, David Brown  wrote:
>>> On 22/11/2019 09:37, Keith Thompson wrote:
>>>> Christian Gollwitzer <auriocus@gmx.de> writes:
>>>>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
>>>> [...]
>>>>>> However, for your purposes std::uint32_t should work fine.
>>>>>
>>>>> Why not
>>>>>
>>>>> #pragma pack(1)
>>>>> struct pixel {
>>>>> 	uint8_t red, green, blue, alpha;
>>>>> }
>>>>>
>>>>> ? That would make more sense to me than uint32_t and bit-twiddling to
>>>>> get the channel values.
>>>>
>>>> Because #pragma pack is non-standard?
>>>>
>>>> If you only care about implementations that support it as an extension,
>>>> that's fine, but the OP seemed very concerned about portability.
>>>>
>>>> An array of uint8_t could also work:
>>>>
>>>>      typedef uint8_t pixel[4];
>>>>      enum { red, green, blue, alpha };
>>>>> Or an array wrapped in a struct to allow assignment.  (An array of 4
>>>> uint8_t elements is guaranteed to be 32 bits, but a struct containing
>>>> such an array is not -- but it's a nearly safe assumption that there
>>>> will be no padding between the elements or at the end.)
>>>>
>>>
>>> While it is true in theory that a struct can have extra padding at the
>>> end (beyond what is needed for an array of the struct to have proper
>>> alignment for all members), are there any compilers that have done so in
>>> practice?
>>>
>>> Another option is to cover all bases with a union:
>>>
>>> typedef union {
>>> 	uint32_t combined;
>>> 	uint8_t rgba[4];
>>> 	struct {
>>> 		uint8_t red, green, blue, alpha;
>>> 	};
>>> } pixel;
>>>
>>> _Static_assert(sizeof(pixel) == 4, "This only works on real systems!");
>>>
>>> (Watch out for endian issues giving different orders within these parts
>>> - that's always a concern for portable code when matching external file
>>> formats.)
>>
>> It usually works in practice but is undefined behavior in C++, so Bjarne
>> Stroustrup and Herb Sutter suggest against it in C++ Core Guidelines.
>>
>> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ru-pun
>>
> 
> You are right - I was thinking in C terms, where this /is/ defined
> behaviour.  For C++, you'd need to put it all in a class and make
> appropriate accessor functions.  On the plus side, that would let you
> make an endian-independent solution, and if it is done well the
> compiler's optimiser will eliminate all overhead.

It is defined behavior in C++ too, but you have to pay extra care 
(compared to C) in order to ensure that only the active member is accessed.

> 
> On some compilers, like gcc, the union type-punning is guaranteed to
> work in C++ too.  But then the code is not portable.
> 

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

#69998

On 22/11/2019 17:13, Manfred wrote:
> On 11/22/2019 12:38 PM, David Brown wrote:
>> On 22/11/2019 11:23, Öö Tiib wrote:
>>> On Friday, 22 November 2019 11:10:26 UTC+2, David Brown  wrote:
>>>> On 22/11/2019 09:37, Keith Thompson wrote:
>>>>> Christian Gollwitzer <auriocus@gmx.de> writes:
>>>>>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
>>>>> [...]
>>>>>>> However, for your purposes std::uint32_t should work fine.
>>>>>>
>>>>>> Why not
>>>>>>
>>>>>> #pragma pack(1)
>>>>>> struct pixel {
>>>>>>     uint8_t red, green, blue, alpha;
>>>>>> }
>>>>>>
>>>>>> ? That would make more sense to me than uint32_t and bit-twiddling to
>>>>>> get the channel values.
>>>>>
>>>>> Because #pragma pack is non-standard?
>>>>>
>>>>> If you only care about implementations that support it as an
>>>>> extension,
>>>>> that's fine, but the OP seemed very concerned about portability.
>>>>>
>>>>> An array of uint8_t could also work:
>>>>>
>>>>>      typedef uint8_t pixel[4];
>>>>>      enum { red, green, blue, alpha };
>>>>>> Or an array wrapped in a struct to allow assignment.  (An array of 4
>>>>> uint8_t elements is guaranteed to be 32 bits, but a struct containing
>>>>> such an array is not -- but it's a nearly safe assumption that there
>>>>> will be no padding between the elements or at the end.)
>>>>>
>>>>
>>>> While it is true in theory that a struct can have extra padding at the
>>>> end (beyond what is needed for an array of the struct to have proper
>>>> alignment for all members), are there any compilers that have done
>>>> so in
>>>> practice?
>>>>
>>>> Another option is to cover all bases with a union:
>>>>
>>>> typedef union {
>>>>     uint32_t combined;
>>>>     uint8_t rgba[4];
>>>>     struct {
>>>>         uint8_t red, green, blue, alpha;
>>>>     };
>>>> } pixel;
>>>>
>>>> _Static_assert(sizeof(pixel) == 4, "This only works on real systems!");
>>>>
>>>> (Watch out for endian issues giving different orders within these parts
>>>> - that's always a concern for portable code when matching external file
>>>> formats.)
>>>
>>> It usually works in practice but is undefined behavior in C++, so Bjarne
>>> Stroustrup and Herb Sutter suggest against it in C++ Core Guidelines.
>>>
>>> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ru-pun
>>>
>>
>> You are right - I was thinking in C terms, where this /is/ defined
>> behaviour.  For C++, you'd need to put it all in a class and make
>> appropriate accessor functions.  On the plus side, that would let you
>> make an endian-independent solution, and if it is done well the
>> compiler's optimiser will eliminate all overhead.
> 
> It is defined behavior in C++ too, but you have to pay extra care
> (compared to C) in order to ensure that only the active member is accessed.
> 

I was assuming Öö meant that type punning via the union - accessing the
same data via the different union members - was undefined behaviour (as
it is, in C++).  Using the union while only accessing the active member
is of course well defined - otherwise the union concept would be pretty
useless!

But it would have been worth making that point more clearly.

>>
>> On some compilers, like gcc, the union type-punning is guaranteed to
>> work in C++ too.  But then the code is not portable.
>>
> 

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

#69990

On 11/22/19 4:10 AM, David Brown wrote:
> On 22/11/2019 09:37, Keith Thompson wrote:
...
>> Or an array wrapped in a struct to allow assignment.  (An array of 4
>> uint8_t elements is guaranteed to be 32 bits, but a struct containing
>> such an array is not -- but it's a nearly safe assumption that there
>> will be no padding between the elements or at the end.)
>>
> 
> While it is true in theory that a struct can have extra padding at the
> end (beyond what is needed for an array of the struct to have proper
> alignment for all members), are there any compilers that have done so in
> practice?

I can't name names, but my understanding is that there have been (and
might still be) implementations where all struct types have the same
alignment requirement as the most strictly aligned type supported by
that implementation. If that alignment requirement is greater than the
requirements of any of the member types, that will sometimes require
padding at the end of the struct.

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

#69991

On 11/22/19 10:49 AM, James Kuyper wrote:
> On 11/22/19 4:10 AM, David Brown wrote:
>> On 22/11/2019 09:37, Keith Thompson wrote:
> ...
>>> Or an array wrapped in a struct to allow assignment.  (An array of 4
>>> uint8_t elements is guaranteed to be 32 bits, but a struct containing
>>> such an array is not -- but it's a nearly safe assumption that there
>>> will be no padding between the elements or at the end.)
>>>
>>
>> While it is true in theory that a struct can have extra padding at the
>> end (beyond what is needed for an array of the struct to have proper
>> alignment for all members), are there any compilers that have done so in
>> practice?
> 
> I can't name names, but my understanding is that there have been (and
> might still be) implementations where all struct types have the same
> alignment requirement as the most strictly aligned type supported by
> that implementation. If that alignment requirement is greater than the
> requirements of any of the member types, that will sometimes require
> padding at the end of the struct.
I said that wrong. Unless all members of the struct have the maximum
alignment requirement, it's possible that such an implementation would
have to put padding at the end.

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

#70092

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 11/22/19 10:49 AM, James Kuyper wrote:
>
>> On 11/22/19 4:10 AM, David Brown wrote:
>>
>>> On 22/11/2019 09:37, Keith Thompson wrote:
>>
>> ...
>>
>>>> Or an array wrapped in a struct to allow assignment.  (An array of 4
>>>> uint8_t elements is guaranteed to be 32 bits, but a struct containing
>>>> such an array is not -- but it's a nearly safe assumption that there
>>>> will be no padding between the elements or at the end.)
>>>
>>> While it is true in theory that a struct can have extra padding at the
>>> end (beyond what is needed for an array of the struct to have proper
>>> alignment for all members), are there any compilers that have done so in
>>> practice?
>>
>> I can't name names, but my understanding is that there have been (and
>> might still be) implementations where all struct types have the same
>> alignment requirement as the most strictly aligned type supported by
>> that implementation.  If that alignment requirement is greater than the
>> requirements of any of the member types, that will sometimes require
>> padding at the end of the struct.
>
> I said that wrong.  Unless all members of the struct have the maximum
> alignment requirement, it's possible that such an implementation would
> have to put padding at the end.

Don't you mean, unless the last member of a struct has the
maximum alignment requirement, it's possible such an
implementation would have to put padding at the end.

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

#69973

Il 22/11/19 09:37, Keith Thompson ha scritto:
> Christian Gollwitzer <auriocus@gmx.de> writes:
>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
> [...]
>>> However, for your purposes std::uint32_t should work fine.
>>
>> Why not
>>
>> #pragma pack(1)
>> struct pixel {
>> 	uint8_t red, green, blue, alpha;
>> }
>>
>> ? That would make more sense to me than uint32_t and bit-twiddling to
>> get the channel values.
> 
> Because #pragma pack is non-standard?
> 
> If you only care about implementations that support it as an extension,
> that's fine, but the OP seemed very concerned about portability.
> 
> An array of uint8_t could also work:
> 
>      typedef uint8_t pixel[4];

intresting idea !!!

>      enum { red, green, blue, alpha };

btw since here #pragma pack seems supported, I find the 
"dot" member selector not only clearer (more readable) but 
more amenable to "intellisense" when typing (type less, no 
typos as autocompletion pops up the members).

but your solution is elegant in that uses more intrinsic 
features

> 
> Or an array wrapped in a struct to allow assignment.  (An array of 4
> uint8_t elements is guaranteed to be 32 bits, but a struct containing

actually I have the struct with individual "channels" 
blended in a UNION with a u_int_32_t  32 bit value, which I 
use when I have to do fast memberwise copy (operator =, 
copy-constructor) or even apply bitwise operators on all 
members at a time (like NOT, XOR etc).
I dunno whether being aligned to the same initial address 
changes anything ... after having used  u_int_8_t (four 
distinct members) even without the #pragma directive the 
compiler does not detect further PADDING issues (a feature 
that it has just proved itself to be well aware of despite 
my ignoring that before)


> such an array is not -- but it's a nearly safe assumption that there
> will be no padding between the elements or at the end.)
> 


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

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

#69999

Soviet_Mario <SovietMario@CCCP.MIR> writes:
> Il 22/11/19 09:37, Keith Thompson ha scritto:
>> Christian Gollwitzer <auriocus@gmx.de> writes:
>>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
>> [...]
>>>> However, for your purposes std::uint32_t should work fine.
>>>
>>> Why not
>>>
>>> #pragma pack(1)
>>> struct pixel {
>>> 	uint8_t red, green, blue, alpha;
>>> }
>>>
>>> ? That would make more sense to me than uint32_t and bit-twiddling to
>>> get the channel values.
>> 
>> Because #pragma pack is non-standard?
>> 
>> If you only care about implementations that support it as an extension,
>> that's fine, but the OP seemed very concerned about portability.
>> 
>> An array of uint8_t could also work:
>> 
>>      typedef uint8_t pixel[4];
>
> intresting idea !!!
>
>>      enum { red, green, blue, alpha };
>
> btw since here #pragma pack seems supported, I find the 
> "dot" member selector not only clearer (more readable) but 
> more amenable to "intellisense" when typing (type less, no 
> typos as autocompletion pops up the members).

If you have a struct consisting of 4 uint8_t members, it's very
likely that you don't *need* #pragma pack.  There might be some
odd compiler out there that allocates more than 32 bits for such
a struct -- but that odd compiler might not support #pragma pack.

    struct pixel {
        uint8_t red;
        uint8_t green;
        uint8_t blue;
        uint8_t alpha;
    };

If you need to write 100% portable code, that might not be good
enough -- but you very likely don't need to write 100% portable code.
(And if you're willing to consider #pragma pack, it seems you
already know that.)

My point in suggesting an array was simply to approach that 100%
portability, but I don't think it's necessary.

[...]

-- 
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]

#69969

On 22/11/2019 07:26, Christian Gollwitzer wrote:
> Am 21.11.19 um 17:20 schrieb Paavo Helde:
>> On 21.11.2019 13:53, Soviet_Mario wrote:
>>> My only requirement is that the plain native type BYTE used in gambas
>>> code that calls the C++ static library and that expects a 8-bit wide
>>> unsigned integral, find its matching type in the C++ code, as they need
>>> to share bitmaps and transparency maps.
>>
>> This is easy, use unsigned char or std::uint8_t.
>>
>>> The bitmaps use 32-bit packed colors+alpha channel, so I was assuming no
>>> difficulty in exchange.
>>
>> This is more tricky because the size of int or long varies much more
>> than char. For example, long is 32 bits in 64-bit MSVC and 64 bits
>> with 64-bit gcc on Linux.
>>
>> However, for your purposes std::uint32_t should work fine.
> 
> Why not
> 
> #pragma pack(1)
> struct pixel {
>     uint8_t red, green, blue, alpha;
> }
> 
> ? That would make more sense to me than uint32_t and bit-twiddling to
> get the channel values.
> 
> Christian

If you are using "pragma pack" (or gcc "packed" attribute), you are
probably doing something wrong.  It can have some uses when dealing with
file formats or network packets with unaligned fields.  But most of the
cases I see - such as this one (and the OP's first suggestion) are
misunderstandings and misuses.

When you use "pragma pack", you are making code that is non-standard,
non-portable, and can cause trouble interacting with other code.  (What
happens when you mix pointers to a packed version of your struct, and a
non-packed version?  Are they compatible?  Will your compiler warn you
of mixups?  My guess is you don't know, and that is not a good thing.)

They can lead to inefficiencies - on some compilers and targets, packed
fields are accessed by byte.  Even when the fields are accessed by their
full size, packed means you can get misalignments, which can have a very
significant impact on efficiency in some situations.

They can lead to restrictions in the code.  For some tools, you can't
take the address of a packed field, or you might see problems using it
because the compiler assumes pointers are properly aligned and that
might not be the case for packed fields.

In short, "packed" can lead to a lot of extra complications and
muck-ups.  Perhaps the most insidious aspect is that /usually/ you don't
see problems with them.  Things will work while you are writing /this/
code, and testing it with /this/ compiler - the problems will turn up
later when someone else gets trouble using the code in a different
project, and won't know why.

So use "packed" only when you /really/ need to - when it is clearly the
best solution to the problem.  And only when you /really/ understand
what it does, and why it might be useful.

And clearly, in this case, it is utterly pointless.  Just write the
struct directly - it is impossible for "pack" to be of any help here.
And if you don't understand that, you certainly should not be using
"pack".  (And you can ask here for more help in understanding, if this
post is not sufficient.)

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

#69971

On Friday, 22 November 2019 10:37:59 UTC+2, David Brown  wrote:
> 
> When you use "pragma pack", you are making code that is non-standard,
> non-portable, and can cause trouble interacting with other code.  (What
> happens when you mix pointers to a packed version of your struct, and a
> non-packed version?  Are they compatible?  Will your compiler warn you
> of mixups?  My guess is you don't know, and that is not a good thing.)

Both gcc and clang have -Waddress-of-packed-member but AFAIK you
won't get that warning when compiling for platform on what it does not
matter.

> They can lead to inefficiencies - on some compilers and targets, packed
> fields are accessed by byte.  Even when the fields are accessed by their
> full size, packed means you can get misalignments, which can have a very
> significant impact on efficiency in some situations.

Huh? Packed structs usually lead to raise of storage efficiency.
Say there is struct containing a char and double. Normally it is 16 bytes
but packed it is  9 bytes. 43.75% of storage saved!
Where we have to process large array of those there it is often impossible
to predict without profiling on target platform if that will cause performance
gain or loss.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web