On Sat, Apr 12, 2014 at 1:11 PM, Mostafa
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
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 speciļ¬es 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