Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69929 > unrolled thread
| Started by | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| First post | 2019-11-20 19:55 +0100 |
| Last post | 2019-11-28 13:21 -0800 |
| Articles | 7 on this page of 67 — 14 participants |
Back to article view | Back to comp.lang.c++
[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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-22 22:04 -0800 |
| Message-ID | <ln4kyvxh5k.fsf@kst-u.example.com> |
| In reply to | #70000 |
Soviet_Mario <SovietMario@CCCP.MIR> writes:
[...]
> let's say it explicitely
>
> if I have
> union
> {
> struct
> {
> u_int_8 Red, Green, Blue, Alpha;
> };
> u_int_32 AllChannels;
> };
>
> without PRAGMA, do I have any explicit or implicit warranty
> that my union be 32 bit long ? If so, PRAGMA is useless. If
> not, it seems it might be useful.
Fixing the spelling of uintN_t (n=8,32) and adding a tag to the union so
you can use it to define objects:
union u {
struct {
uint8_t Red, Green, Blue, Alpha;
};
uint32_t AllChannels;
};
(You have an anonymous struct, which is standard but wasn't added until
C11, so older compilers might not support it, or might not support it
by default.)
You're guaranteed that the Red and AllChannels members start at the same
location, the very beginning of the union. You're guaranteed that Red,
Green, Blue, and Alpha are at increasing offsets in the order you
defined them.
It's very very likely that the struct and the union will both be
exactly 32 bits. A compiler is not prohibited from adding padding
between members or after the last one, but there's unlikely to be
any good reason to do so in this case. The most likely way this
could fail is if a compiler insisted on making the structure 64 bits.
You can easily add a compile-time or run-time assertion that
sizeof (struct u) == 4 && CHAR_BIT == 8
so your program won't compile, or at least won't run, in the
unlikely event that it's used with an implementation that doesn't
meet your requirements.
There is *no* guarantee about which of the four uint8_t members
correspond to which part of AllChannels. Google "endianness" if
you're not familiar with this. It's very common for Red to overlap
either the high-order byte or the low-order byte of AllChannels.
The other 22 permutations are rare or nonexistent, but Google
"PDP-11 middle-endian" for an odd case.
If you're doing bitwise operations on the entire 32-bit word without
caring about the order of the bytes, then that might not be an issue.
Attempting to use #pragma pack is very likely to do nothing *at best*.
[...]
--
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]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-11-23 11:26 +0100 |
| Message-ID | <qrb1ga$5ls$1@dont-email.me> |
| In reply to | #70006 |
Il 23/11/19 07:04, Keith Thompson ha scritto:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
> [...]
>> let's say it explicitely
>>
>> if I have
>> union
>> {
>> struct
>> {
>> u_int_8 Red, Green, Blue, Alpha;
>> };
>> u_int_32 AllChannels;
>> };
>>
>> without PRAGMA, do I have any explicit or implicit warranty
>> that my union be 32 bit long ? If so, PRAGMA is useless. If
>> not, it seems it might be useful.
>
> Fixing the spelling of uintN_t (n=8,32) and adding a tag to the union so
> you can use it to define objects:
again ...
Keith, I did not edit the header manually, and sized ints
HERE are spelled as I wrote.
...omissis...
#ifdef __USE_MISC
/* Old compatibility names for C types. */
typedef unsigned long int ulong;
typedef unsigned short int ushort;
typedef unsigned int uint;
#endif
/* These size-specific names are used by some of the inet
code. */
#if !__GNUC_PREREQ (2, 7)
/* These types are defined by the ISO C99 header
<inttypes.h>. */
# ifndef __int8_t_defined
# define __int8_t_defined
typedef char int8_t;
typedef short int int16_t;
typedef int int32_t;
# if __WORDSIZE == 64
typedef long int int64_t;
# else
__extension__ typedef long long int int64_t;
# endif
# endif
/* But these were defined by ISO C without the first `_'. */
typedef unsigned char u_int8_t;
typedef unsigned short int u_int16_t;
typedef unsigned int u_int32_t;
# if __WORDSIZE == 64
typedef unsigned long int u_int64_t;
# else
__extension__ typedef unsigned long long int u_int64_t;
# endif
typedef int register_t;
#else
/* For GCC 2.7 and later, we can use specific type-size
attributes. */
# define __intN_t(N, MODE) \
typedef int int##N##_t __attribute__ ((__mode__ (MODE)))
# define __u_intN_t(N, MODE) \
typedef unsigned int u_int##N##_t __attribute__
((__mode__ (MODE)))
# ifndef __int8_t_defined
# define __int8_t_defined
__intN_t (8, __QI__);
__intN_t (16, __HI__);
__intN_t (32, __SI__);
__intN_t (64, __DI__);
# endif
__u_intN_t (8, __QI__);
__u_intN_t (16, __HI__);
__u_intN_t (32, __SI__);
__u_intN_t (64, __DI__);
typedef int register_t __attribute__ ((__mode__ (__word__)));
...omissis...
as you can see the types are spelled as I wrote them, and a
search for uintXX_t does not find anything
is this that big problem ?
I guess the variations stands for the same concept
>
> union u {
> struct {
> uint8_t Red, Green, Blue, Alpha;
> };
> uint32_t AllChannels;
> };
>
> (You have an anonymous struct, which is standard but wasn't added until
> C11, so older compilers might not support it, or might not support it
> by default.)
it gives me warnings indeed, but seems to compile nevertheless
>
> You're guaranteed that the Red and AllChannels members start at the same
> location, the very beginning of the union. You're guaranteed that Red,
> Green, Blue, and Alpha are at increasing offsets in the order you
> defined them.
>
> It's very very likely that the struct and the union will both be
> exactly 32 bits. A compiler is not prohibited from adding padding
> between members or after the last one,
and that was the reason why I had thought of trying to give
it a strong hint not to pad by mean of a #pragma pack directive
> but there's unlikely to be
> any good reason to do so in this case. The most likely way this
> could fail is if a compiler insisted on making the structure 64 bits.
so either it packs natively, either it listens to my
explicit hint, either it ignore the #pragma and does not pack.
Does the #pragma directive increase, decrease, not affect
the likelyhood of packing ? That was the reasoning behind my
approach
I thought : I give you an hint : TRY to pack. If you really
cannot, there is nothing else I could do
>
> You can easily add a compile-time or run-time assertion that
> sizeof (struct u) == 4 && CHAR_BIT == 8
that's a very good idea !
> so your program won't compile, or at least won't run, in the
> unlikely event that it's used with an implementation that doesn't
> meet your requirements.
>
> There is *no* guarantee about which of the four uint8_t members
> correspond to which part of AllChannels.
and I don't need such warranty : I use AllChannels only for
mass-copying, assignments, copy constructor. When I need
access to separate channels I use named members.
> Google "endianness" if
> you're not familiar with this.
I just know the problem but I am not familiar in the sense I
had never had to write pieces of code depending on this aspect
> It's very common for Red to overlap
> either the high-order byte or the low-order byte of AllChannels.
Yes, but I did no assumption about the order of bytes in the
"long" int
> The other 22 permutations are rare or nonexistent, but Google
> "PDP-11 middle-endian" for an odd case.
>
> If you're doing bitwise operations
no, I chose the struct right to avoid that.
My only possible and very unlikely source of problems could
be if Gambas and C++ has a mean to use a different bit
ordering within a byte.
I did not even give a thought, it seemed to me more an
hardware related feature so transparent to both gambas and C++
> on the entire 32-bit word without
> caring about the order of the bytes, then that might not be an issue.
>
> Attempting to use #pragma pack is very likely to do nothing *at best*.
well ... until now, I am thinking it is likely to do nothing
*at worst* as no one has explained which drawbacks it were
supposed to be in the particular case (I'm not referring to
other more general examples with longer integers
hypothetically spanning non multiple addresses : here I have
1 byte sizes, and the only big member starts at 0 offset)
>
> [...]
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-23 12:27 -0800 |
| Message-ID | <lnzhgmwd7n.fsf@kst-u.example.com> |
| In reply to | #70010 |
Soviet_Mario <SovietMario@CCCP.MIR> writes:
> Il 23/11/19 07:04, Keith Thompson ha scritto:
>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>> [...]
>>> let's say it explicitely
>>>
>>> if I have
>>> union
>>> {
>>> struct
>>> {
>>> u_int_8 Red, Green, Blue, Alpha;
>>> };
>>> u_int_32 AllChannels;
>>> };
>>>
>>> without PRAGMA, do I have any explicit or implicit warranty
>>> that my union be 32 bit long ? If so, PRAGMA is useless. If
>>> not, it seems it might be useful.
>>
>> Fixing the spelling of uintN_t (n=8,32) and adding a tag to the union so
>> you can use it to define objects:
>
> again ...
> Keith, I did not edit the header manually, and sized ints
> HERE are spelled as I wrote.
[SNIP]
> as you can see the types are spelled as I wrote them, and a
> search for uintXX_t does not find anything
I didn't know where the names u_int_8 and u_int_32 came from,
and assumed they were misspellings of uint8_t and uint32_t.
On my own system, #include <sys/types.h> introduces the non-standard
type names u_int{8,32}_t. It doesn't introduce u_int_{8,32}, and I
don't see that name in the code you quoted (other than in your union
definition) or anywhere under /usr/include on my system.
On the other hand, the types uint8_t and uint32_t are defined by the C
and C++ standards (starting with C99 and C++11, respectively).
Nobody is suggesting that you're lying or manually editing headers. All
we're saying is that uint8_t and uint32_t are the *standard* types that
meet your requirements, and there is no good reason to use non-standard
types with similar names.
Do you have some reason to prefer to use u_int_8 rather than uint8_t?
> is this that big problem ?
> I guess the variations stands for the same concept
Yes. Names other than uint8_t are non-standard and will cause your code
not to compile in many environments.
>> union u {
>> struct {
>> uint8_t Red, Green, Blue, Alpha;
>> };
>> uint32_t AllChannels;
>> };
>>
>> (You have an anonymous struct, which is standard but wasn't added until
>> C11, so older compilers might not support it, or might not support it
>> by default.)
>
> it gives me warnings indeed, but seems to compile nevertheless
What warnings? If you compile with "gcc -std=c11" or with a
sufficiently new version of gcc, there shouldn't be any.
Always pay attention to warnings.
[...]
>> It's very very likely that the struct and the union will both be
>> exactly 32 bits. A compiler is not prohibited from adding padding
>> between members or after the last one,
>
> and that was the reason why I had thought of trying to give
> it a strong hint not to pad by mean of a #pragma pack directive
If it works without a non-standard #pragma pack, why would you add it?
You risk your code failing to compile, or compiling incorrectly, with an
implementation that doesn't support #pragma pack or that does something
unexpected.
>> but there's unlikely to be
>> any good reason to do so in this case. The most likely way this
>> could fail is if a compiler insisted on making the structure 64 bits.
>
> so either it packs natively, either it listens to my
> explicit hint, either it ignore the #pragma and does not pack.
>
> Does the #pragma directive increase, decrease, not affect
> the likelyhood of packing ? That was the reasoning behind my
> approach
>
> I thought : I give you an hint : TRY to pack. If you really
> cannot, there is nothing else I could do
There's no guarantee that all compilers will understand your "hint",
and nothing in the standard that says anything at all about what
"#pragma pack" does.
[...]
>> There is *no* guarantee about which of the four uint8_t members
>> correspond to which part of AllChannels.
>
> and I don't need such warranty : I use AllChannels only for
> mass-copying, assignments, copy constructor. When I need
> access to separate channels I use named members.
What operations do you need on AllChannels that you can't perforom on
the struct? You can assign structs.
[...]
>> Attempting to use #pragma pack is very likely to do nothing *at best*.
>
> well ... until now, I am thinking it is likely to do nothing
> *at worst* as no one has explained which drawbacks it were
> supposed to be in the particular case (I'm not referring to
> other more general examples with longer integers
> hypothetically spanning non multiple addresses : here I have
> 1 byte sizes, and the only big member starts at 0 offset)
The drawback of #pragma pack is that it's non-standard. Given the
concern you've expressed about portability, I would think that would
be important to you. And given that it will almost certainly do
nothing, I don't know why you're so insistent on using it.
--
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]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-11-24 00:54 +0100 |
| Message-ID | <qrcgr3$8gm$1@dont-email.me> |
| In reply to | #70018 |
On 23/11/2019 21:27, Keith Thompson wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>> Il 23/11/19 07:04, Keith Thompson ha scritto:
>>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>> [...]
>>>> let's say it explicitely
>>>>
>>>> if I have
>>>> union
>>>> {
>>>> struct
>>>> {
>>>> u_int_8 Red, Green, Blue, Alpha;
>>>> };
>>>> u_int_32 AllChannels;
>>>> };
>>>>
>>>> without PRAGMA, do I have any explicit or implicit warranty
>>>> that my union be 32 bit long ? If so, PRAGMA is useless. If
>>>> not, it seems it might be useful.
>>>
>>> Fixing the spelling of uintN_t (n=8,32) and adding a tag to the union so
>>> you can use it to define objects:
>>
>> again ...
>> Keith, I did not edit the header manually, and sized ints
>> HERE are spelled as I wrote.
> [SNIP]
>> as you can see the types are spelled as I wrote them, and a
>> search for uintXX_t does not find anything
>
> I didn't know where the names u_int_8 and u_int_32 came from,
> and assumed they were misspellings of uint8_t and uint32_t.
>
> On my own system, #include <sys/types.h> introduces the non-standard
> type names u_int{8,32}_t. It doesn't introduce u_int_{8,32}, and I
> don't see that name in the code you quoted (other than in your union
> definition) or anywhere under /usr/include on my system.
yes I miss-spelled forgetting the final _t (but the pieces
of headers pasted mentioned it)
>
> On the other hand, the types uint8_t and uint32_t are defined by the C
> and C++ standards (starting with C99 and C++11, respectively).
>
> Nobody is suggesting that you're lying or manually editing headers. All
> we're saying is that uint8_t and uint32_t are the *standard* types that
> meet your requirements, and there is no good reason to use non-standard
> types with similar names.
>
> Do you have some reason to prefer to use u_int_8 rather than uint8_t?
no no reason at all. I just noticed this subtle difference
after having rewritten always :)
But It will take short to do a mass-replace and change the
included header
>
>> is this that big problem ?
>> I guess the variations stands for the same concept
>
> Yes. Names other than uint8_t are non-standard and will cause your code
> not to compile in many environments.
well I must have mis-expressed again when I said I was
looking for a portable way, I actually meant I needed a way
that allowed proper data exchange from front-end gambas side
and C++ engine.
I'll never deploy the program anywhere else. So as long as
it compiles here, fine enough
>
>
>>> union u {
>>> struct {
>>> uint8_t Red, Green, Blue, Alpha;
>>> };
>>> uint32_t AllChannels;
>>> };
>>>
>>> (You have an anonymous struct, which is standard but wasn't added until
>>> C11, so older compilers might not support it, or might not support it
>>> by default.)
>>
>> it gives me warnings indeed, but seems to compile nevertheless
>
> What warnings?
that anonymous structs (or unions) are non standard and
supported only with GCC later than some version.
I'm using the "native" (= preinstalled) GCC here on MX (QT
itself did not ship with any own compiler in the free
version). I have installed the later build-essentials from
"stable" repository. I'm not very willing to update from
testing or backport.
Maybe if I found some flatpak or appimage version, more
isolated.
> If you compile with "gcc -std=c11" or with a
> sufficiently new version of gcc, there shouldn't be any.
I'm looking to assess the GCC version here (on Debian its a
bit older still).
back
here I have GCC 4:6.3.0-4
(and supporting packages seem 6.3.0-18)
anche il CPP riporta la stessa signature.
I found a 9.4-2 MX version and I'm adding it too.
I don't know if QT ide will automatically detect it (and I'm
sure I won't be able to configure it, otherwise)
>
> Always pay attention to warnings.
It was reading the "padding" warning that all this odessy
began :)
>
> [...]
>
>>> It's very very likely that the struct and the union will both be
>>> exactly 32 bits. A compiler is not prohibited from adding padding
>>> between members or after the last one,
>>
>> and that was the reason why I had thought of trying to give
>> it a strong hint not to pad by mean of a #pragma pack directive
>
> If it works without a non-standard #pragma pack, why would you add it?
> You risk your code failing to compile, or compiling incorrectly, with an
> implementation that doesn't support #pragma pack or that does something
> unexpected.
>
>>> but there's unlikely to be
>>> any good reason to do so in this case. The most likely way this
>>> could fail is if a compiler insisted on making the structure 64 bits.
>>
>> so either it packs natively, either it listens to my
>> explicit hint, either it ignore the #pragma and does not pack.
>>
>> Does the #pragma directive increase, decrease, not affect
>> the likelyhood of packing ? That was the reasoning behind my
>> approach
>>
>> I thought : I give you an hint : TRY to pack. If you really
>> cannot, there is nothing else I could do
>
> There's no guarantee that all compilers will understand your "hint",
I just use GCC, not others
> and nothing in the standard that says anything at all about what
> "#pragma pack" does.
>
> [...]
>
>>> There is *no* guarantee about which of the four uint8_t members
>>> correspond to which part of AllChannels.
>>
>> and I don't need such warranty : I use AllChannels only for
>> mass-copying, assignments, copy constructor. When I need
>> access to separate channels I use named members.
>
> What operations do you need on AllChannels that you can't perforom on
> the struct? You can assign structs.
uhm ... memberwise or all-at-once ?
I thought struct assignment (normally I wrote operator =)
should pass through memberwise copying.
So the aim was to copy everything in one assignment only
instead of four of them.
But if struct can be assigned smartly enough then the union
is not needed.
Also I duplicated pixel addressing. One slower way through
operator () (int row, int column) and a massive one
dimensional linear addressing for mass processing of all pixels.
>
> [...]
>
>>> Attempting to use #pragma pack is very likely to do nothing *at best*.
>>
>> well ... until now, I am thinking it is likely to do nothing
>> *at worst* as no one has explained which drawbacks it were
>> supposed to be in the particular case (I'm not referring to
>> other more general examples with longer integers
>> hypothetically spanning non multiple addresses : here I have
>> 1 byte sizes, and the only big member starts at 0 offset)
>
> The drawback of #pragma pack is that it's non-standard. Given the
> concern you've expressed about portability,
sorry I realize I had been unwittingly misleading. I was
just thinking of interoperate gambas code and library code.
As long as it works on my two couple of machines that would
be enough. I have Linux MX on both, BTW, among other things
> I would think that would
> be important to you. And given that it will almost certainly do
> nothing, I don't know why you're so insistent on using it.
>
oh, sorry at last for my often unclear English. I tend to
sow misunderstandings everywhere due to this :\
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-23 17:06 -0800 |
| Message-ID | <lnr21yw09k.fsf@kst-u.example.com> |
| In reply to | #70025 |
Soviet_Mario <SovietMario@CCCP.MIR> writes:
> On 23/11/2019 21:27, Keith Thompson wrote:
>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>> Il 23/11/19 07:04, Keith Thompson ha scritto:
>>>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>>> [...]
>>>>> let's say it explicitely
>>>>>
>>>>> if I have
>>>>> union
>>>>> {
>>>>> struct
>>>>> {
>>>>> u_int_8 Red, Green, Blue, Alpha;
>>>>> };
>>>>> u_int_32 AllChannels;
>>>>> };
>>>>>
>>>>> without PRAGMA, do I have any explicit or implicit warranty
>>>>> that my union be 32 bit long ? If so, PRAGMA is useless. If
>>>>> not, it seems it might be useful.
>>>>
>>>> Fixing the spelling of uintN_t (n=8,32) and adding a tag to the union so
>>>> you can use it to define objects:
>>>
>>> again ...
>>> Keith, I did not edit the header manually, and sized ints
>>> HERE are spelled as I wrote.
>> [SNIP]
>>> as you can see the types are spelled as I wrote them, and a
>>> search for uintXX_t does not find anything
>>
>> I didn't know where the names u_int_8 and u_int_32 came from,
>> and assumed they were misspellings of uint8_t and uint32_t.
>>
>> On my own system, #include <sys/types.h> introduces the non-standard
>> type names u_int{8,32}_t. It doesn't introduce u_int_{8,32}, and I
>> don't see that name in the code you quoted (other than in your union
>> definition) or anywhere under /usr/include on my system.
>
> yes I miss-spelled forgetting the final _t (but the pieces
> of headers pasted mentioned it)
To be very clear, if you need an unsigned integer type of at least 8
bits, there is almost no good reason not to use uint8_t. There is no
good reason to use some system-specific (or even undocumented)
equivalent.
"Almost" means you might have to consider older implementations that
don't support <stdint.h> / <cstdint>. Any version of g++ you're likely
to encounter should support C++11 or later -- older versions might
require an explicit option. Even older versions are likely to support
<stdint.h> or <cstdint> as an extension.
>> On the other hand, the types uint8_t and uint32_t are defined by the C
>> and C++ standards (starting with C99 and C++11, respectively).
>>
>> Nobody is suggesting that you're lying or manually editing headers. All
>> we're saying is that uint8_t and uint32_t are the *standard* types that
>> meet your requirements, and there is no good reason to use non-standard
>> types with similar names.
>>
>> Do you have some reason to prefer to use u_int_8 rather than uint8_t?
>
> no no reason at all. I just noticed this subtle difference
> after having rewritten always :)
> But It will take short to do a mass-replace and change the
> included header
>
>>
>>> is this that big problem ?
>>> I guess the variations stands for the same concept
>>
>> Yes. Names other than uint8_t are non-standard and will cause your code
>> not to compile in many environments.
>
>
> well I must have mis-expressed again when I said I was
> looking for a portable way, I actually meant I needed a way
> that allowed proper data exchange from front-end gambas side
> and C++ engine.
>
> I'll never deploy the program anywhere else. So as long as
> it compiles here, fine enough
If you use uint8_t it will compile.
>>
>>
>>>> union u {
>>>> struct {
>>>> uint8_t Red, Green, Blue, Alpha;
>>>> };
>>>> uint32_t AllChannels;
>>>> };
>>>>
>>>> (You have an anonymous struct, which is standard but wasn't added until
>>>> C11, so older compilers might not support it, or might not support it
>>>> by default.)
>>>
>>> it gives me warnings indeed, but seems to compile nevertheless
>>
>> What warnings?
>
> that anonymous structs (or unions) are non standard and
> supported only with GCC later than some version.
It's always better to copy-and-paste diagnostic messages rather than
trying to summarize them.
BTW, I made a serious mistake here. C supports anonymous structs as
of C11. C++ does not support them at all. g++ does support them as
an extension. With "g++ -std=c17 -pedantic", I get "warning: ISO C++
prohibits anonymous structs [-Wpedantic]". My apologies for that.
If you're only using gcc, you can use anonymous structs in C++,
but your code will be non-portable.
[...]
>>>> There is *no* guarantee about which of the four uint8_t members
>>>> correspond to which part of AllChannels.
>>>
>>> and I don't need such warranty : I use AllChannels only for
>>> mass-copying, assignments, copy constructor. When I need
>>> access to separate channels I use named members.
>>
>> What operations do you need on AllChannels that you can't perforom on
>> the struct? You can assign structs.
>
> uhm ... memberwise or all-at-once ?
> I thought struct assignment (normally I wrote operator =)
> should pass through memberwise copying.
> So the aim was to copy everything in one assignment only
> instead of four of them.
> But if struct can be assigned smartly enough then the union
> is not needed.
The semantics of struct assignment (assuming you haven't overloaded
operator=) are equivalent to the semantics of copying memberwise,
but in the case of a struct containing 4 uint8_t members, no sane
compiler will do anything other than a 32-bit copy. That's assuming
the struct has an alignment that permits a 32-bit copy.
If copying the entire structure is the only operation you care about,
keep it simple: just define the structure and use ordinary structure
assignment.
[...]
--
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]
| From | Soviet_Mario <SovietMario@CCCP.MIR> |
|---|---|
| Date | 2019-11-24 12:10 +0100 |
| Message-ID | <qrdoe9$qdb$1@dont-email.me> |
| In reply to | #70026 |
On 24/11/2019 02:06, Keith Thompson wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>> On 23/11/2019 21:27, Keith Thompson wrote:
>>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>>> Il 23/11/19 07:04, Keith Thompson ha scritto:
>>>>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>>>> [...]
>>>>>> let's say it explicitely
>>>>>>
>>>>>> if I have
>>>>>> union
>>>>>> {
>>>>>> struct
>>>>>> {
>>>>>> u_int_8 Red, Green, Blue, Alpha;
>>>>>> };
>>>>>> u_int_32 AllChannels;
>>>>>> };
>>>>>>
>>>>>> without PRAGMA, do I have any explicit or implicit warranty
>>>>>> that my union be 32 bit long ? If so, PRAGMA is useless. If
>>>>>> not, it seems it might be useful.
>>>>>
>>>>> Fixing the spelling of uintN_t (n=8,32) and adding a tag to the union so
>>>>> you can use it to define objects:
>>>>
>>>> again ...
>>>> Keith, I did not edit the header manually, and sized ints
>>>> HERE are spelled as I wrote.
>>> [SNIP]
>>>> as you can see the types are spelled as I wrote them, and a
>>>> search for uintXX_t does not find anything
>>>
>>> I didn't know where the names u_int_8 and u_int_32 came from,
>>> and assumed they were misspellings of uint8_t and uint32_t.
>>>
>>> On my own system, #include <sys/types.h> introduces the non-standard
>>> type names u_int{8,32}_t. It doesn't introduce u_int_{8,32}, and I
>>> don't see that name in the code you quoted (other than in your union
>>> definition) or anywhere under /usr/include on my system.
>>
>> yes I miss-spelled forgetting the final _t (but the pieces
>> of headers pasted mentioned it)
>
> To be very clear, if you need an unsigned integer type of at least 8
well strictly speaking I need a type of EXACTLY 8 bits, not more
> bits, there is almost no good reason not to use uint8_t. There is no
> good reason to use some system-specific (or even undocumented)
> equivalent.
>
> "Almost" means you might have to consider older implementations that
> don't support <stdint.h> / <cstdint>. Any version of g++ you're likely
> to encounter should support C++11 or later -- older versions might
> require an explicit option. Even older versions are likely to support
> <stdint.h> or <cstdint> as an extension.
>
>>> On the other hand, the types uint8_t and uint32_t are defined by the C
>>> and C++ standards (starting with C99 and C++11, respectively).
>>>
>>> Nobody is suggesting that you're lying or manually editing headers. All
>>> we're saying is that uint8_t and uint32_t are the *standard* types that
>>> meet your requirements, and there is no good reason to use non-standard
>>> types with similar names.
>>>
>>> Do you have some reason to prefer to use u_int_8 rather than uint8_t?
>>
>> no no reason at all. I just noticed this subtle difference
>> after having rewritten always :)
>> But It will take short to do a mass-replace and change the
>> included header
>>
>>>
>>>> is this that big problem ?
>>>> I guess the variations stands for the same concept
>>>
>>> Yes. Names other than uint8_t are non-standard and will cause your code
>>> not to compile in many environments.
>>
>>
>> well I must have mis-expressed again when I said I was
>> looking for a portable way, I actually meant I needed a way
>> that allowed proper data exchange from front-end gambas side
>> and C++ engine.
>>
>> I'll never deploy the program anywhere else. So as long as
>> it compiles here, fine enough
>
> If you use uint8_t it will compile.
>
>>>
>>>
>>>>> union u {
>>>>> struct {
>>>>> uint8_t Red, Green, Blue, Alpha;
>>>>> };
>>>>> uint32_t AllChannels;
>>>>> };
>>>>>
>>>>> (You have an anonymous struct, which is standard but wasn't added until
>>>>> C11, so older compilers might not support it, or might not support it
>>>>> by default.)
>>>>
>>>> it gives me warnings indeed, but seems to compile nevertheless
>>>
>>> What warnings?
>>
>> that anonymous structs (or unions) are non standard and
>> supported only with GCC later than some version.
>
> It's always better to copy-and-paste diagnostic messages rather than
> trying to summarize them.
well, I did not copy the warning when the compiler produced it.
I would have to re-edit the source (or restore the older
version) to just replicate the output ... maybe messing sth :\
>
> BTW, I made a serious mistake here. C supports anonymous structs as
> of C11. C++ does not support them at all. g++ does support them as
> an extension. With "g++ -std=c17 -pedantic", I get "warning: ISO C++
> prohibits anonymous structs [-Wpedantic]". My apologies for that.
no problem !!! this is not an helpdesk, I get the good
offered for free with good intention. That's more than enough !
>
> If you're only using gcc, you can use anonymous structs in C++,
> but your code will be non-portable.
yes only GCC.
BTW : as I feared, QT (even after a system reboot ...
actually power went off tonight, here it poured dogs and
cats ! 160 mm of rain in 24 hours, a disaster) did not
automatically detect the new version from MX repo. it just
still see the original version.
I'll see to this later If i find how to configure it (and
locate it first)
>
> [...]
>
>>>>> There is *no* guarantee about which of the four uint8_t members
>>>>> correspond to which part of AllChannels.
>>>>
>>>> and I don't need such warranty : I use AllChannels only for
>>>> mass-copying, assignments, copy constructor. When I need
>>>> access to separate channels I use named members.
>>>
>>> What operations do you need on AllChannels that you can't perforom on
>>> the struct? You can assign structs.
>>
>> uhm ... memberwise or all-at-once ?
>> I thought struct assignment (normally I wrote operator =)
>> should pass through memberwise copying.
>> So the aim was to copy everything in one assignment only
>> instead of four of them.
>> But if struct can be assigned smartly enough then the union
>> is not needed.
>
> The semantics of struct assignment (assuming you haven't overloaded
> operator=) are equivalent to the semantics of copying memberwise,
> but in the case of a struct containing 4 uint8_t members, no sane
> compiler will do anything other than a 32-bit copy. That's assuming
> the struct has an alignment that permits a 32-bit copy.
I would think that the existence of such monolythic member
should ensure the alignment.
I should look the asm generated, but I can't be bothered :) :)
>
> If copying the entire structure is the only operation you care about,
> keep it simple: just define the structure and use ordinary structure
> assignment.
>
> [...]
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-28 13:21 -0800 |
| Message-ID | <86lfrzae8o.fsf@linuxsc.com> |
| In reply to | #69929 |
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 ?
>
> 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)
I would offer an alternate set of suggestions.
First, pick a name for the type you will use in your code. For
example, in this case, you might pick 'GamByte' as the type
name you will be using.
Second, see if the library being used (Gambas) supplies a name
for its type in one of its headers. If it does, define your
type name in terms of that. These names might even be the same,
except they might be declared in different namespaces.
Third, if the library being used does not supply a name for the
type it is using, but just spells out the concrete type in its
function declarations, etc, define your type name as that, eg,
using GamByte = unsigned char; // for use with Gambas
where 'unsigned char' is meant to be the type given in Gambas
header files, assuming there is one.
Fourth, if the library being used does NOT have the type in
question appear in any of its header files, use 'unsigned char'.
If it's important to guarantee that the type is exactly eight
bits, use a static assertion that CHAR_BIT == 8. The reason
is that 'unsigned char' is guaranteed to work, if any type
is, and if for any reason it doesn't work then the error message
produced by the static assertion will be more easily understood
than, eg, a syntax error trying to use a non-existent uint8_t.
Fifth, if you never need individual 8-bit bytes in isolation, but
only in aggregates (arrays or array-like), you might consider
defining the aggregate type as a struct inside a template, which
externally could look like an array of 8-bit types even though
internally it might be, eg, 32-bit unsigned words used to hold
four 8-bit values.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c++
csiph-web