What\'s the difference between sizeof and alignof?
#include
#define SIZEOF_ALIGNOF(T) std::cout<< sizeof(T) << \'/\' << a
The alignof value is the same as the value for sizeof for basic types.
The difference lies in used defined data types such as using struct; for an e.g.
typedef struct { int a; double b; } S;
//cout<<alignof(s); outputp: 8;
//cout<<sizeof(S); output: 12;
hence the sizeof value is the total size required for the given data type; and alignof value is the alignment requirement of the largest element in the structure.
Use of alignof : allocate memory on a particular alignment boundary.
Old question (although not marked as answered..) but thought this example makes the difference a bit more explicit in addition to Christian Stieber's answer. Also Meluha's answer contains an error as sizeof(S) output is 16 not 12.
// c has to occupy 8 bytes so that d (whose size is 8) starts on a 8 bytes boundary
// | 8 bytes | | 8 bytes | | 8 bytes |
struct Bad { char c; double d; int i; };
cout << alignof(Bad) << " " << sizeof(Bad) << endl; // 8 24
// | 8 bytes | | 8 bytes |
struct Good { double d; int i; char c; };
cout << alignof(Good) << " " << sizeof(Good) << endl; // 8 16
It also demonstrates that it is best ordering members by size with largest first (double in this case), as the others members are constrained by that member.
What's the difference between
sizeof
andalignof
?
Both are operators. Both return a type of size_t
.
sizeof
is the size in "bytes" of the object - the memory space needed to encode it.
alignof
is the address alignment requirement in "bytes" of the object. A value of 1 implies no alignment restriction. 2 implies the address should be an even address. 4 implies the address should be a quad address. etc.
When an object reference is attempted that does not meet the alignment requirement, the result is undefined behavior.
Examples:
. The access may work, only slower.
. The access attempt may kill the program.
// Assume alignof(int) --> 2
char a[4]; // It is not known that `a` begins on an odd or even address
int *p = a; // conversion may fail
int d = *p; // *p is UB.
Example extension and output of OP's code.
SIZEOF_ALIGNOF(double);
SIZEOF_ALIGNOF(complex double);
SIZEOF_ALIGNOF(div_t);
SIZEOF_ALIGNOF(max_align_t);
8/8
16/8
8/4
32/16
For the answers provided, there seems to be some confusion about what alignment actually is. The confusion probably arises because there are 2 kinds of alignment.
1. Member alignment
This is a qualitative measure that spells out how large an instance is in number of bytes for a specific ordering of the members within the structure/class type. Generally, compilers can compact structure/class instances if the members are ordered by their byte-size in descending order (i.e. largest first, smallest members last) within the structure. Consider:
struct A
{
char c; float f; short s;
};
struct B
{
float f; short s; char c;
};
Both structures contain exactly the same information. For the sake of this example; the float type takes 4 bytes, the short type takes 2 and the character takes 1 byte. However, the first structure A has members in random order, while second structure B orders members according to their byte size (this may be different on certain architectures, I'm assuming x86 intel CPU architecture with 4-byte alignment in this example). Now consider the size of the structures:
printf("size of A: %d", sizeof (A)); // size of A: 12;
printf("size of B: %d", sizeof (B)); // size of B: 8;
If you would expect the size to be 7 bytes, you would be assuming that the members are packed into the structure using a 1-byte alignment. While some compilers allow this, in general most compilers use 4-byte or even 8-byte alignments due to historic reasons (most CPU's work with DWORD (double-word) or QWORD (quad-word) general purpose registers).
There are 2 padding mechanisms at work to achieve the packing.
First, each member that has a byte size smaller than the byte-alignment is 'merged' with the next member(s) if the resulting byte size is smaller or equal to the byte-alignment. In structure B, members s and c can be merged in this way; their combined size is 2 bytes for s + 1 byte for c == 3 bytes <= 4-byte alignment. For structure A, no such merging can occur, and each member effectively consumes 4 bytes in the structure's packing.
The total size of the structure is again padded so that the next structure can start at the alignment boundary. In example B the total number of bytes would be 7. The next 4-byte boundary lies at byte 8, hence the structure is padded with 1 byte to allow array allocations as a tight sequence of instances.
Note that Visual C++ / GCC allow different alignments of 1 byte, 2 and higher multiples of 2 bytes. Understand that this works against your compiler's ability to produce optimal code for your architecture. Indeed, in the following example, each byte would be read as a single byte using a single-byte instruction for each read operation. In practice, the hardware would still fetch the entire memory line that contains each byte read into the cache, and execute the instruction 4 times, even if the 4 bytes sit in the same DWORD and could be loaded in the CPU register in 1 instruction.
#pragma pack(push,1)
struct Bad
{
char a,b,c,d;
};
#pragma pack(pop)
2. Allocation alignment
This is closely related to the 2nd padding mechanism explained in the previous section, however, allocation alignments can be specified in variants of malloc/memalloc allocation functions, e.g. std::aligned_alloc(). Hence, it is possible to allocate an object at a different (typically higher multiple of 2) alignment boundary than the structure/object type's byte-alignment suggests.
size_t blockAlignment = 4*1024; // 4K page block alignment
void* block = std::aligned_alloc(blockAlignment, sizeof(T) * count);
The code will place the block of count instances of type T on addresses that end on multiples of 4096.
The reason for using such allocation alignments are again purely architectural. For instance, reading and writing blocks from page-aligned addresses is faster because the range of addresses fit nicely into the cache layers. Ranges that are split over different 'pages' trash the cache when crossing the page boundary. Different media (bus architectures) have different access patterns and may benefit from different alignments. Generally, alignments of 4, 16, 32 and 64 K page sizes are not uncommon.
Note that the language version and platform will usually provide a specific variant of such aligned allocation functions. Eg.g the Unix/Linux compatible posix_memalign function return the memory by ptr argument and returns non-zero error values in case of failure.
The sizeof operator gives you the size in bytes of an actual type or instance of a type.
The alignof operator gives you the alignment in bytes required for any instance of the given type.
Well, "memory" is basically a huge array of bytes. However, most larger things like integers need more than 1 byte to store them -- a 32 bit value, for example, would use 4 consecutive bytes of memory.
Now, the memory modules in your computer aren't usually "bytes"; they are also organized with a few bytes "in parallel", like blocks of 4 bytes.
For a CPU, it's much easier = more efficient = better performance to not "cross" such block-borders when reading something like an integer:
memory byte 0 1 2 3 4 5 6 7 8 9 10 11
integer goooood
baaaaaaaaad
This is what the "alignment" says: an alignment of 4 means that data of this type should (or must, depends on the CPU) be stored starting at an address that is a multiple of 4.
You observation that sizeof==alignof is incorrect; try structures. Structures will also be aligned (because their individual members need to end up on the correct addresses), but their size will be much larger.