?
Solved

structure

Posted on 2013-06-18
10
Medium Priority
?
253 Views
Last Modified: 2013-07-06
How does the compiler pads a structure? Does it always pads sequentially?
Consider a 64 bit machine


struct PAD {
   uint32_t a;
   uint32_t b;
   uint64_t c;
   uint32_t d;
   // Will it add 4 bytes padding at the end or can it pad anywhere?
}
0
Comment
Question by:perlperl
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 2
  • +2
10 Comments
 
LVL 46

Accepted Solution

by:
Kent Olsen earned 2000 total points
ID: 39257778
It depends mostly on the compiler options.

The selected alignment may cause the items in the structure to be packed (no padding) or aligned at the 16, 32, or 64 bit mark.  If alignment is at 64 bits, there will be padding after every item that is shorter than 64 bits, or any array that is isn't a multiple of 64 bits.



Good Luck,
Kent
0
 
LVL 86

Expert Comment

by:jkr
ID: 39257780
Padding always occurs at the end of a structure, otherwise that would not make sense at all. In your above case, no padding will occur anyway, since the structure already is 4-byte-aligned. It would be different if it was like this:

struct PAD {
   uint32_t a;
   uint32_t b;
   uint64_t c;
   uint32_t d;
   char f;
   // 3 padding bytes will be added here unless specified differently
} 

Open in new window

0
 
LVL 84

Expert Comment

by:ozo
ID: 39257805
Each non-bit-field member of a structure or union object is aligned in an implementationdefined
manner appropriate to its type.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 

Author Comment

by:perlperl
ID: 39257919
in my case it does add 4 bytes padding
0
 
LVL 86

Expert Comment

by:jkr
ID: 39257928
I don't think so - the struct size is 16 bytes, and that should be what 'sizeof()' reports.
0
 
LVL 46

Expert Comment

by:Kent Olsen
ID: 39258109
Hi perl,

What you're probably seeing is that the structure is packed (no padding between the variables) and a total of 20 bytes in length.

  PAD pad_array[2];

Then depending on the data alignment option, the array above will pad the array so that each item starts on a 64-bit boundary.


Kent
0
 
LVL 86

Expert Comment

by:jkr
ID: 39258186
Kdo,,

a 20-byte sized struct isn't really well-aligned for 64 bit adresses either... something is quite confusing about this whole setup.
0
 
LVL 46

Expert Comment

by:Kent Olsen
ID: 39258997
Hi jkr,

I think that it can be explained simply by data alignment and structure blocking.  If data alignment is to the word (64 bits) and structures are not packed, there will be a half word of padding after each 32-bit entity.  

If alignment is to the half-word (32 bits) or packed structures are forced due to a PRAGMA or other compiler option, then there will be no padding in the structure.


Kent
0
 
LVL 84

Expert Comment

by:ozo
ID: 39261206
You can use the offsetof and sizeof macros to determine where and whether padding was added in your implementation.
0
 
LVL 35

Expert Comment

by:sarabande
ID: 39283740
at win7-64 bit  vc compiler with 8-byte alignment i have

struct PAD {
   UINT32 a;
   UINT32 b;
   UINT64 c;
   UINT32 d;
//   char e;
}; 

int main(int argc, char **argv)
{
    PAD pad;
    std::cout << (int)((UINT64)(void*)&pad.b-(UINT64)(void*)&pad.a) << "|" 
              << (int)((UINT64)(void*)&pad.c-(UINT64)(void*)&pad.a) << "|"
              << (int)((UINT64)(void*)&pad.d-(UINT64)(void*)&pad.a) << "|"
//              << (int)((UINT64)(void*)&pad.e-(UINT64)(void*)&pad.a) << "|"
              << (int)(sizeof(pad)) << std::endl;

Open in new window


the output was

4|8|16|24

what pretty much is that i expected.

with the char member e, the output was

4|8|16|20|24

what also is consequent.

the rule is that padding was done if next member would not begin at an alignment fitting to its own size or would overlap the required alignment. so an 4-byte integer always would begin at a 4-byte segment. a single char can begin at next byte regardless of alignment.  

struct PAD 
{
   UINT32 a;
   UINT32 b;
   UINT64 c;
   char d[5];
   char e;
   short f;
   UINT32 g;
};

Open in new window


4|8|16|21|22|24|32

you see the char e begins at an odd byte and short f very well can be put packed between e and g.

Sara
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction This article is a continuation of the C/C++ Visual Studio Express debugger series. Part 1 provided a quick start guide in using the debugger. Part 2 focused on additional topics in breakpoints. As your assignments become a little more …
Windows programmers of the C/C++ variety, how many of you realise that since Window 9x Microsoft has been lying to you about what constitutes Unicode (http://en.wikipedia.org/wiki/Unicode)? They will have you believe that Unicode requires you to use…
The goal of this video is to provide viewers with basic examples to understand opening and writing to files in the C programming language.
The goal of this video is to provide viewers with basic examples to understand how to use strings and some functions related to them in the C programming language.
Suggested Courses

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question