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

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

[QT creator on "nix"] - "outer" padding within arrays of structures - was 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"] - "outer" padding within arrays of structures - was getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 13:17 +0100
    Re: [QT creator on "nix"] - "outer" padding within arrays of structures - was getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-23 12:35 -0800

#70011 — [QT creator on "nix"] - "outer" padding within arrays of structures - was getting a strict 8 bit (1 byte) array with no padding

I have realized I don't know an aspect of padding vs packing 
management.

In the other thread I have been explained of the aspects of 
padding/packing INSIDE a given structure/class/union and 
similar.

But now I realize I know nothing for sure about packing in 
between different element within arrays of such 
structure/class/union and similar.

for a start I haven't found a documentation about the 
#pragma pack directive applied to a whole array

is it possible (and how) to suggest the compiler to pack 
items ? (*)
Are there differences in the outcome of such hints depending 
on actual size of the packed structures ?
I am figuring out a packed struct of ODD total size, when 
allocated in an array, it could lead to either non packed 
array or to addresses in ODD/EVEN pattern (is it possible ? 
Non asking if efficient, just possible).


secondly, how much is it, reasonably, the no-padding 
threshold in an array of class/struct/union objects ?

There is some criterion, preferably less restrictive than 
"powers of two" size of objects" ?

I feel quite sure that 64 bit  multiple are packed without 
any suggestion.
But, for example, 32 bit ? 16 bit ?

The hardware per se has no problem : in fact it can manage 
COMPACT arrays of native types (int, short int) without 
memory waste. I would hope that the same could hold for 
structured types of the same size, but not so sure.
What is the truth ?


Could packing (assuming it is possible to force the compiler 
to do it) lead to addressing problems (of the contained data 
member) ?
I am not speaking about SLOWING problems, but strictly 
crashes or silent wrong addressing or ... dunno !

TY



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

[toc] | [next] | [standalone]

#70019

Soviet_Mario <SovietMario@CCCP.MIR> writes:
> I have realized I don't know an aspect of padding vs packing 
> management.
>
> In the other thread I have been explained of the aspects of 
> padding/packing INSIDE a given structure/class/union and 
> similar.
>
> But now I realize I know nothing for sure about packing in 
> between different element within arrays of such 
> structure/class/union and similar.

Packing for arrays is not a thing.

Every object type has a constant size, which you can query using sizeof.
Each element of an array is allocated the size of the element's type.

For example, given:

    some_type arr[N];

it's guaranteed that sizeof (arr) == N * sizeof (some_type).  (We can
use that to determine the number of elements in an array: sizeof arr /
sizeof arr[0]).

If a non-standard #pragma pack has been applied to some_type itself,
that might change the value of sizeof (some_type), but it does not
change the relationship between sizeof (some_type) and sizeof
(some_type[N]).

The size of any type is a multiple of its alignment, which is what
makes arrays possible.

If some_type is

    struct some_type {
        long big;
        char small;
    };

then there is likely to be padding after small, precisely so that in an
array of some_type elements each big sub-element is correctly aligned.
The padding is within the structure.  There is no padding between array
elements.

[...]

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

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

csiph-web