Re: [boost] [align] Review - Impl Evaluation Part 1.

Subject: Re: [boost] [align] Review - Impl Evaluation Part 1.
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2014-04-12 16:31:10

On Sat, Apr 12, 2014 at 1:11 PM, Mostafa <mostafa_working_away_at_[hidden]> wrote:
> Unfortunately I don't understand what you're trying to say. Additionally let
> me rephrase my question, why is it that in the absence of a
> platform-specific aligned_alloc the boost provided aligned_alloc silently
> aligns on alignof(void *) if the user requested alignment value is less than
> alignof(void *)? (I understand this is still correct behaviour, just curious
> since the boost provided aligned_alloc uses boost::align to align the memory
> buffer and, per your previous response, "An alignment smaller than
> alignof(void*) is still a valid fundamental alignment, so align() should be
> usable with such values.")

Ah, I had misinterpreted your question. The reason why the
Boost-provided aligned_alloc will ensure alignment is a minimum of
alignof(void*), is because after calling align(), we want to access
the sizeof(void*) bytes immediately preceding the aligned memory as a
void*, so that address must be suitably aligned for void*.

Instead of *(static_cast<void*>(p1) - 1) = p2; I could have used
std::memcpy to copy p2 into that storage, and then it would not
require that storage to be at-least alignof(void*) aligned.

> Actually it doesn't imply that, and I was wrong in my original assertion,
> 17.6.3.5/2:
>
> "Table 28 describes the requirements on allocator types
> and thus on types used to instantiate allocator_traits. A requirement is
> optional if the last column of
> Table 28 specifies a default for a given expression."
>
> and "a.allocate(n, u)" defaults to "a.allocate(n)" in the said table.

*Nod*. Alternatively one could say that maybe the adaptor should only
provide an allocate(n, hint) overload if the inner allocator fit
provides an allocate(n, u) overload, but I prefer this design.

Glen