centaurian_slug
centaurian_slug

Reputation: 3399

std::array alignment

Trying out std::tr1::array on a mac i'm getting 16 byte alignment.

sizeof(int) = 4;  
sizeof( std::tr1::array< int,3 > ) = 16;  
sizeof( std::tr1::array< int,4 > ) = 16;    
sizeof( std::tr1::array< int,5 > ) = 32;

Is there anything in the STL that behaves like array< T,N > but is guaranteed to NOT pad itself out, i.e.

sizeof( ARRAY< T, N> ) = sizeof(  T )*N  

Upvotes: 11

Views: 4776

Answers (4)

Ernavar
Ernavar

Reputation: 21

The standard mandates that the elements "are stored contiguously, meaning that if a is an array<T, N>, then it obeys the identity &a[n] == &a[0] + n for all 0 <= n < N." (23.3.2.1 [array.overview] paragraph 1)

As far as I know, there is no guarantee that sizeof (std::array<T, N>) == sizeof (T) * N, but the contiguity statement asserts that the values are stored just like in a regular C array. If you only have one array of values that need to be contiguous, you can use sizeof (T) * std::array<T, N>::size() as the size and std::array<T, N>::data() as the starting address of the array.

Upvotes: 2

user283145
user283145

Reputation:

std::array is actually not an array, but a struct that contains an array. It's the struct that is padded, not the array. Compilers are allowed to add padding to the end of a struct whenever they want.

Upvotes: 1

centaurian_slug
centaurian_slug

Reputation: 3399

Since posting, turns I get what I want swapping the IDE setting from the default to..

LLVM compiler 3.0 Language:
  LLVM C++ standard library:
    =libc++ (LLVM standard library with c++0x support.)

( CLANG_CXX_LIBRARY = libc++ )l

Previously the setting was "libstdc++ (gcc c++ standard library)" which appears to have the padding, and that allowed me to include <array> instead of <tr1/array>; and now

sizeof(array<T,N>)==sizeof(T)*N

this is all in Xcode 4.2 on mac osx lion. I'm hoping one is simply deprecated and that this behavior is what i'll get on other platforms?

Upvotes: 0

semisight
semisight

Reputation: 964

It looks from what little data you've given like it allocates memory to the nearest power of two. Knowing very little CPU architecture details, I might guess that allocating power-of-two sizes is faster than non padded, at least for small amounts. Perhaps you should see what happens when you try to allocate something a much larger?

Is there any reason you absolutely positively need to skim those extra bytes off the top?

Upvotes: 0

Related Questions