Variables memory placement

[Kent-Dorfman]

Since op stated that a struct of structs is not an option, then all bets are off. Even then, the #pragma pack() would be necessary to guarantee packed alignment of the elements (no holes).

A vector of structs would guarantee continuity but not packed alignment.

[JonB]

Firstly, I really don't think it's a good idea to try having separately-declared variables and then relying on their adjacent declarations in code causing adjacent layout. It's not very language-y, you are relying on compiler behaviour. Just not a good idea.

Secondly, as it stands the OP cannot do

if the structures were contiguous, my handler could update that widgets just having a unique pointer, the address of the first structure

as simply as he implies. As written, these are separate struct types. That means they could have different member types, so you cannot assume one struct is the same size as another, and therefore you cannot "march through them" with a fixed size.

It's important the OP states whether these structs are actually all the same struct type (as they are in the code he shows) or not. In which case he should change to use the same struct type.

An array is the only way to safely guarantee layout order. If they are all the same type he can have an array of them. If they are not, then he would have to have an array of unions of all the struct types. You can then march through them via the array index, they are adjacent, and FWIW each one occupies &array[1] - &array[0] bytes.

Another way to "march through" of course is, after the variables are defined, to have an array of pointers to initialized to point to each of the variables, and use that to address them in a loop.

[Vittorio61]

Thanks for your replies. Despite of the examples the structures are very different one from the others. I tried with #pragma and it works as expected for the variables in a structure, but not between the structures. I checked the addressess: the following structures seems to be always aligned module 8. I'll have some other tests and if this is the only problem I will align my structures with fillers. In that case I'll consider this topic as "solved".

[Christian Ehrlicher]

@Vittorio61 said in Variables memory placement:

I checked the addressess: the following structures seems to be always aligned module 8.

since you're on 64bit, the alignment is 8bytes (64bits)
But the order is not defined by definiton. So you need to create a big struct with proper pack and fill bytes.

[JonB]

@Vittorio61
As I and @Christian-Ehrlicher said

But the order is not defined by definiton.

So your concept may be relying on compiler/platform implementation, and may not hold elsewhere.... Up to you.

[Vittorio61]

Thanks to all, I wil take up all your suggestions and try to adapt my software accordingly.

[Chris Kawa]

@Vittorio61 said in Variables memory placement:

I tried with #pragma and it works as expected for the variables in a structure, but not between the structures

Like others mentioned you'd have to pack the stuctures and the class that houses the variables, so e.g.

#pragma pack(1)
class Foo
{
   #pragma pack(1)
   struct
   {
   ...
   } myStruct_1;

   #pragma pack(1)
   struct
   {
   ...
   } myStruct_2;
};

Keep in mind that alignment is there for a reason and packing it this way hinders the performance of the class, because all access to it becomes unaligned and thus more costly.

[Christian Ehrlicher]

@Chris-Kawa This will still lead to an alignment of 4 or 8 for myStruct_2 which may not be what the op wants.

[Chris Kawa]

@Christian-Ehrlicher said:

This will still lead to an alignment of 4 or 8 for myStruct_2

It shouldn't. The packing of the outer class should take care of that. It does at least on MSVC: https://godbolt.org/z/4vvPxY

[Kent-Dorfman]

we're getting into very compiler/platform specific features with trying to stuff the data and using pragmas to do it. I've learned to avoid it altogether and to defined memory regions as simple uint8_t vectors, then to write accessor methods that push and pull the data by brute force and bit shifting/stuffing. I must do this a lot with ad-hoc networking protocols. One thing you never want to do is

int v =*(int*)&(vec[17]);

at the minimum it creates an innefficient memory access, and at the maximum generates an alignment fault on some processors. The better way is:

int v;
memcpy(&v, &vec[17], sizeof(int));

manually setting significant bit order if necessary