1) What is your evaluation of the design?
###########################
align/aligned_allocator.hpp
###########################
What about generalizing the interface of aligned_allocator to allow
type-specific
alignment values? I know this was discussed on the mailing list and there
was
some concern about interface complexity, that is having to define a
metafunction
for the degenerate but common case where all types should be aligned
equally.
I think that concern can be addressed and still allow interface
flexibility with
something along the lines of the following:
template struct
aligned_allocator;
template
struct uniform_alignment_traits
{
template <typename T>
struct alignment_of
{
static std::size_t const value = Alignment;
};
};
template
struct aligned_allocator
: public aligned_allocator
{
};
where the second parameter can be an mpl::size_t type or a type with a
nested
single argument template class named "alignment_of" that has a static
member
variable named value. This allows for the degenerate case to be easily
declared
as: "aligned_allocator >" and yet still preserve the
option
of specifying per-type alignment requirements.
####################################
align/aligned_allocator_adaptor.hpp
####################################
The same remarks about generalizing the interface as in
"align/aligned_allocator.hpp".
IMO, "class aligned_allocator_adaptor : public Allocator" is a bad design.
One, conceptually aligned_allocator_adaptor is not an "Allocator" because
it
overrides some of "Allocator"'s core functionality, and two, it enables the
following surprising behaviour:
aligned_allocator_adaptor aaa;
some_existing_allocator & sea = aaa;
aaa.allocate(...) != sea.allocate(...)
aaa.deallocate(...) != sea.deallocate(...)
Inheritance should be private with the appropiate adapted-to-allocator's
traits
being brought in with using statements or adapted-to-allocator should be a
member variable of aligned_allocator_adaptor.
As an aside, a general allocator_adaptor class would be useful, something
along
the lines of the following:
template
struct allocator_adaptor;
that defaults to std::allocator_traits for the standard
required
allocator type members not defined in DERIVED.
~~~~~~~~~~~~~~~~~~~
... allocator() ...
~~~~~~~~~~~~~~~~~~~
I suggest renaming the member function "allocator()" to
"base_allocator()". One
too many times I thought it referred to the allocator adaptor itself.
~~~~~
ctors
~~~~~
Why isn't a general forward-to-base-allocator constructor provided?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<class A> explicit aligned_allocator_adaptor(A&& alloc)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is this function intended to forward *any* single argument to the base
class
constructor? If so, then the argument name "alloc" is misleading and
should be
changed. If not, then is the intent to forward some base class allocator of
arbitrary type, like the following:
template <class A>
explicit aligned_allocator_adaptor(
typename Traits:: template rebind<A>::other && alloc)
template <class A>
explicit aligned_allocator_adaptor(
typename Traits:: template rebind<A>::other & alloc)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template <class A> explicit aligned_allocator_adaptor(const A& alloc)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Same question as its C++11 counterpart.
####################
align/is_aligned.hpp
####################
As noted elsewhere, I think the name "is_aligned_to" more clear expresses
this
function's intent than "is_aligned".
