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

On Sat, 12 Apr 2014 02:58:48 -0700, Glen Fernandes wrote:

On Sat, Apr 12, 2014 at 2:21 AM, Mostafa wrote:

...

Should "alignment" be silently set to alignof(void *) if its more weak than alignof(void *), or should the restrictions on "alignment" be a precondition for calling this function and a BOOST_ASSERT check be made on it. Either way it should be noted in the documentation. (More importantly, does this silent behaviour also apply to the provided platform specific aligned_alloc functions?) The intention is that aligned_alloc() should have the same requirements whether it uses my implementation, MSVC's, POSIX's, or any other. So if a particular implementation specific version has stronger requirements for the value of 'alignment', my inline aligned_alloc wrapper around that particular platform-specific function will relax those requirements (by rounding up 'alignment' if necessary).

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.")

...

pointer allocate(size_type size, const_void_pointer hint) Is the preprocessor conditional code really needed? Can't it all be replaced by "a1.allocate(...)" since "a1" is required by the standard to define such a function?

While [allocator.requirements] implies that every allocator should provide an overload for allocate() that takes hint, [allocator.traits.members] 20.6.8.2/2 implies that for a given allocator, allocate(n, hint) may not be well-formed, and so allocator_traits<...>::allocate(n, hint) will call allocate(n) if allocate(n, hint) is not well-formed.

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.