Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder7.news.weretis.net!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c++
Subject: Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding
Date: Fri, 22 Nov 2019 10:00:13 -0800
Organization: None to speak of
Lines: 61
Message-ID: <lnk17ryeoi.fsf@kst-u.example.com>
References: <qr4275$hk3$1@dont-email.me> <lnr221zqmu.fsf@kst-u.example.com> <lnimndzq3i.fsf@kst-u.example.com> <qr5tre$mhv$1@dont-email.me> <qr6dgn$j2c$1@dont-email.me> <qr7v3c$lvv$1@dont-email.me> <lnsgmgxq5r.fsf@kst-u.example.com> <qr8cq9$q8p$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="673dee156045fd04bdb03a9da416f64d"; logging-data="20280"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18LQwrqXzEhdDNjL2bGM1uW"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:WXix0mOOROLjnpAnPW2gTy/rDpY= sha1:47EuksEyhmelOmBpM4ebXvuJAcM=
Xref: csiph.com comp.lang.c++: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 */