64

Is allocating a buffer via new char[sizeof(T)] guaranteed to allocate memory which is properly aligned for the type T, where all members of T has their natural, implementation defined, alignment (that is, you have not used the alignas keyword to modify their alignment).

I have seen this guarantee made in a few answers around here but I'm not entirely clear how the standard arrives at this guarantee. 5.3.4-10 of the standard gives the basic requirement: essentially new char[] must be aligned to max_align_t.

What I'm missing is the bit which says alignof(T) will always be a valid alignment with a maximum value of max_align_t. I mean, it seems obvious, but must the resulting alignment of a structure be at most max_align_t? Even point 3.11-3 says extended alignments may be supported, so may the compiler decide on its own a class is an over-aligned type?

Improve this question
12
  • 5
    Finally, a good question. Can I upvote a whole bunch of times? (CLICK CLICK CLICK) Commented May 14, 2012 at 17:07
  • 2
    @JohnDibling: by yourself, no, but there's a bunch of us fortunately :D Commented May 14, 2012 at 17:10
  • 4
    Not an answer, but can't you just play it safe and use new T and cast the result? Oh, and +1 for teaching me a new tag. I never heard about language-lawyer. Commented May 14, 2012 at 17:11
  • 1
    What the spec says about sizeof must be relevant too: 5.3.3-2 says "When applied to a class, the result is the number of bytes in an object of that class including any padding required for placing objects of that type in an array" Commented May 14, 2012 at 17:16
  • 1
    I still don't understand the question. Commented May 14, 2012 at 17:17

2 Answers 2

Reset to default
20

The expressions new char[N] and new unsigned char[N] are guaranteed to return memory sufficiently aligned for any object. See §5.3.4/10 "[...] For arrays of char and unsigned char, the difference between the result of the new-expression and the address returned by the allocation function shall be an integral multiple of the strictest fundamental alignment requirement (3.11) of any object type whose size is no greater than the size of the array being created. [ Note: Because allocation functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating character arrays into which objects of other types will later be placed. —end note ]".

From a stylistic point of view, of course: if what you want is to allocate raw memory, it's clearer to say so: operator new(N). Conceptually, new char[N] creates N char; operator new(N) allocates N bytes.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

It's only required to provide alignment for a type with a fundamental alignment requirement, up to max_align_t. so the question is whether the compiler may create class types of extended alignment, which would thus not be fundamentally aligned.
What does this answer add? The standards quote is the same section is referenced in the question.
I think there may be another consideration here. I would guess that for any type means any fundamental type, such as uint64_t, double, unsigned short etc. To understand where I'm going with this, consider an arbitrary struct. It could be, for example, 3 bytes in size. (eg: 3 chars.) My guess would be that a struct of size 3 bytes will have some padding appended to it. Even with this padding, the padding may not be enough to obtain the correct alignment. So I would guess the compiler does some extra stuff to space out an array of such a struct, so that it does indeed work.
Does anyone have any thoughts on that?
I've just done some testing and this is completely wrong. I will ask another question.
7

What I'm missing is the bit which says alignof(T) will always be a valid alignment with a maximum value of max_align_t. I mean, it seems obvious, but must the resulting alignment of a structure be at most max_align_t ? Even point 3.11-3 says extended alignments may be supported, so may the compiler decide on its own a class is an over-aligned type ?

As noted by Mankarse, the best quote I could get is from [basic.align]/3:

A type having an extended alignment requirement is an over-aligned type. [ Note: every over-aligned type is or contains a class type to which extended alignment applies (possibly through a non-static data member). —end note ]

which seems to imply that extended alignment must be explicitly required (and then propagates) but cannot

I would have prefer a clearer mention; the intent is obvious for a compiler-writer, and any other behavior would be insane, still...

Improve this answer

2 Comments

It uses the word applied, could a compiler apply an extended alignment on its own? Or do points 1/2 in the paragraph to imply that any alignment applied by the compiler must be at most max_align_t?
@edA-qamort-ora-y: [dcl.align]/1 also uses the verb apply: "An alignment-specifier may be applied to", so I would expect that this means that it is where the applies come from and it should be explicitly required but...

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.