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

Subject: Re: [boost] [align] Review - Impl Evaluation Part 1.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2014-04-12 16:11:45

On Sat, 12 Apr 2014 02:58:48 -0700, Glen Fernandes  
<glen.fernandes_at_[hidden]> wrote:

> On Sat, Apr 12, 2014 at 2:21 AM, Mostafa  
> <mostafa_working_away_at_[hidden]> 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.