Alignment guarantees?

B

bytebro

If I declare something like

std::vector<char> buffer(100);

are there any guarantees about the alignment of &buffer[0]? I think
what I'm trying to say is am I allowed to assume that although I've
declared a vector of char, the data-storage area within my vector
might be int-aligned, or even long-long-aligned?
 
I

Ian Collins

bytebro said:
If I declare something like

std::vector<char> buffer(100);

are there any guarantees about the alignment of &buffer[0]? I think
what I'm trying to say is am I allowed to assume that although I've
declared a vector of char, the data-storage area within my vector
might be int-aligned, or even long-long-aligned?

I don't think there is, alignment would be a property of the allocator
used. If the default allocator calls malloc, then the memory will be
suitably aligned.
 
M

Maarten Kronenburg

"bytebro" wrote in message
If I declare something like

std::vector<char> buffer(100);

are there any guarantees about the alignment of &buffer[0]? I think
what I'm trying to say is am I allowed to assume that although I've
declared a vector of char, the data-storage area within my vector
might be int-aligned, or even long-long-aligned?

The current standard draft is document N2461 on:
http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01
and there is something on general alignment in 3.11 and 20.6.7.
The vector however is 23.2.5 and there it is assumed contiguous.
In The C++ Programming Language by Stroustrup (3rd ed) page 102:
"The size of an object of a structure type is not necessarily the sum of the
sizes of its members."
So inside objects alignment is observed, but not in collection classes.
So the answer to your question is no.
But if you need alignment in collection classes you can put your char into
an object (which is aligned) and then make a vector of those objects. Then
you achieve alignment in the vector indirectly.
Maarten.
 
J

Jeff Schwab

Maarten said:
"bytebro" wrote in message
If I declare something like

std::vector<char> buffer(100);

are there any guarantees about the alignment of &buffer[0]? I think
what I'm trying to say is am I allowed to assume that although I've
declared a vector of char, the data-storage area within my vector
might be int-aligned, or even long-long-aligned?

The current standard draft is document N2461 on:
http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01
and there is something on general alignment in 3.11 and 20.6.7.
The vector however is 23.2.5 and there it is assumed contiguous.
In The C++ Programming Language by Stroustrup (3rd ed) page 102:
"The size of an object of a structure type is not necessarily the sum of the
sizes of its members."
So inside objects alignment is observed, but not in collection classes.
So the answer to your question is no.
But if you need alignment in collection classes you can put your char into
an object (which is aligned) and then make a vector of those objects. Then
you achieve alignment in the vector indirectly.
Maarten.

Each element of the vector then requires the alignment, as opposed to
just the first element. The K&R approach to this (see TCPL) was to
allocate an object of union type, where one union element was the
payload type (e.g. char), and another was the alignment type (e.g. int).
This kind of low-level detail has to be handled as the memory is
allocated, or else casts will be required at the higher level. For
std::vector, the right solution seems likely to be a custom allocator.
 
Q

qinghu.liao

If I declare something like

std::vector<char> buffer(100);

are there any guarantees about the alignment of &buffer[0]?  I think
what I'm trying to say is am I allowed to assume that although I've
declared a vector of char, the data-storage area within my vector
might be int-aligned, or even long-long-aligned?

================================================================================
namespace Ogre {

/** Class to provide aligned memory allocate functionality.
@remarks
All SIMD processing are friendly with aligned memory, and some
SIMD routines
are designed for working with aligned memory only. If the data
are intended to
use SIMD processing, it's need to be aligned for better
performance boost.
In additional, most time cache boundary aligned data also lead
to better
performance even if didn't used SIMD processing. So this class
provides a couple
of functions for allocate aligned memory.
@par
Anyways, in general, you don't need to use this class
directly, Ogre internally
will take care with most SIMD and cache friendly optimisation
if possible.
@par
This isn't a "one-step" optimisation, there are a lot of
underlying work to
achieve performance boost. If you didn't know what are you
doing or what there
are going, just ignore this class.
@note
This class intended to use by advanced user only.
*/
class _OgreExport AlignedMemory
{
public:
/** Allocate memory with given alignment.
@param
size The size of memory need to allocate.
@param
alignment The alignment of result pointer, must be
power of two
and in range [1, 128].
@returns
The allocated memory pointer.
@par
On failure, exception will be throw.
*/
static void* allocate(size_t size, size_t alignment);

/** Allocate memory with default platform dependent alignment.
@remarks
The default alignment depend on target machine, this
function
guarantee aligned memory according with SIMD
processing and
cache boundary friendly.
@param
size The size of memory need to allocate.
@returns
The allocated memory pointer.
@par
On failure, exception will be throw.
*/
static void* allocate(size_t size);

/** Deallocate memory that allocated by this class.
@param
p Pointer to the memory allocated by this class or
<b>NULL</b> pointer.
@par
On <b>NULL</b> pointer, nothing happen.
*/
static void deallocate(void* p);
};

/** STL compatible allocator with aligned memory allocate, used
for tweak
STL containers work with aligned memory.
@remarks
This class designed for work with STL containers, by use this
class instead of std::allocator, the STL containers can work
with aligned memory allocate seamless.
@note
template parameter Alignment equal to zero means use default
platform dependent alignment.
*/
template <typename T, unsigned Alignment = 0>
class AlignedAllocator
{
// compile-time check alignment is available.
typedef int IsValidAlignment
[Alignment <= 128 && ((Alignment & (Alignment-1)) == 0) ?
+1 : -1];

public:
//--- typedefs for STL compatible

typedef T value_type;

typedef value_type * pointer;
typedef const value_type * const_pointer;
typedef value_type & reference;
typedef const value_type & const_reference;
typedef std::size_t size_type;
typedef std::ptrdiff_t difference_type;

template <typename U>
struct rebind
{
typedef AlignedAllocator<U, Alignment> other;
};

public:
AlignedAllocator() { /* nothing to do */ }

// default copy constructor

// default assignment operator

// not explicit, mimicking std::allocator [20.4.1]
template <typename U, unsigned A>
AlignedAllocator(const AlignedAllocator<U, A> &) { /* nothing
to do */ }

// default destructor

//--- functions for STL compatible

static pointer address(reference r)
{ return &r; }
static const_pointer address(const_reference s)
{ return &s; }
static size_type max_size()
{ return (std::numeric_limits<size_type>::max)(); }
static void construct(const pointer ptr, const value_type & t)
{ new (ptr) T(t); }
static void destroy(const pointer ptr)
{
ptr->~T();
(void) ptr; // avoid unused variable warning
}

bool operator==(const AlignedAllocator &) const
{ return true; }
bool operator!=(const AlignedAllocator &) const
{ return false; }

static pointer allocate(const size_type n)
{
// use default platform dependent alignment if 'Alignment'
equal to zero.
const pointer ret = static_cast<pointer>(Alignment ?
AlignedMemory::allocate(sizeof(T) * n, Alignment) :
AlignedMemory::allocate(sizeof(T) * n));
return ret;
}
static pointer allocate(const size_type n, const void * const)
{
return allocate(n);
}
static void deallocate(const pointer ptr, const size_type)
{
AlignedMemory::deallocate(ptr);
}
};
}

============================================================
/**
*
* |___2___|3|_________5__________|__6__|
* ^ ^
* 1 4
*
* 1 -> Pointer to start of the block allocated by new.
* 2 -> Gap used to get 4 aligned on given alignment
* 3 -> Byte offset between 1 and 4
* 4 -> Pointer to the start of data block.
* 5 -> Data block.
* 6 -> Wasted memory at rear of data block.
*/

namespace Ogre {

//---------------------------------------------------------------------
void* AlignedMemory::allocate(size_t size, size_t alignment)
{
assert(0 < alignment && alignment <= 128 &&
Bitwise::isPO2(alignment));

unsigned char* p = new unsigned char[size + alignment];
size_t offset = alignment - (size_t(p) & (alignment-1));

unsigned char* result = p + offset;
result[-1] = (unsigned char)offset;

return result;
}
//---------------------------------------------------------------------
void* AlignedMemory::allocate(size_t size)
{
return allocate(size, OGRE_SIMD_ALIGNMENT);
}
//---------------------------------------------------------------------
void AlignedMemory::deallocate(void* p)
{
if (p)
{
unsigned char* mem = (unsigned char*)p;
mem = mem - mem[-1];
delete [] mem;
}
}

}
 
B

bytebro

bytebro said:
If I declare something like
std::vector<char> buffer(100);
are there any guarantees about the alignment of &buffer[0]? I think
what I'm trying to say is am I allowed to assume that although I've
declared a vector of char, the data-storage area within my vector
might be int-aligned, or even long-long-aligned?

I don't think there is, alignment would be a property of the allocator
used. If the default allocator calls malloc, then the memory will be
suitably aligned.

Thanks to all who commented. I think this response captures the nub
of it; since malloc returns a pointer which is "suitably aligned for
any kind of variable", if I have control over the allocator used, I
can control the alignment.
 
J

James Kanze

If I declare something like
std::vector<char> buffer(100);
are there any guarantees about the alignment of
&buffer[0]? I think what I'm trying to say is am I
allowed to assume that although I've declared a vector of
char, the data-storage area within my vector might be
int-aligned, or even long-long-aligned?
I don't think there is, alignment would be a property of the
allocator used. If the default allocator calls malloc, then
the memory will be suitably aligned.
[/QUOTE]

The default allocator is required to call operator new(). Which
also guarantees alignment. However...
Thanks to all who commented. I think this response captures
the nub of it; since malloc returns a pointer which is
"suitably aligned for any kind of variable", if I have
control over the allocator used, I can control the alignment.

There's no guarantee that &buffer[0] returns the address
returned by the allocator, although I can't think of any reason
why this wouldn't be the case. But an implementation would
certainly be allowed to "save" a first entry of type T for some
internal reasons, so that &buffer[0] would be equal to the
address returned by operator new plus sizeof(T).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top