Re: [boost] Review request for Boost.Align

Subject: Re: [boost] Review request for Boost.Align
From: DUPUIS Etienne (e.dupuis_at_[hidden])
Date: 2014-02-20 07:59:34

> -----Message d'origine-----
> De : Boost [mailto:boost-bounces_at_[hidden]] De la part de Andrey
> Semashev
> Envoyé : jeudi 20 février 2014 10:56
> À : boost_at_[hidden]
> Objet : Re: [boost] Review request for Boost.Align
>
> I think it complicates things too much. For example, if I just want to align
> memory at cache line boundary (64 bytes for Intel CPUs), I would have to
> create a metafunction just to provide this single constant to the allocator.
>
> I can understand why you would want to use a metafunction here - you want
> rebound allocator to use the proper alignment. But realistically, no one ever
> wants to align memory weaker than malloc/new, and it is already guaranteed
> to align properly for any builtin types. So you would specify a stronger
> alignment than malloc/new provides, which means it should already be
> strong enough for any T. That's why I think a simple constant would be
> enough.
>
>   template< typename T, unsigned int Alignment = 0 >
>   class aligned_allocator
>   {
>     static constexpr unsigned int alignment = Alignment > 0 ?
> Alignment : alignment_of< T >::value;
>     static_assert(alignment >= alignment_of< T >::value, "Specified alignment
> is too weak");
>   };
>
> But if you decide to go with the metafunction, then at least provide a
> boilerplate so that it is easy to specify a constant.
>

I second Andrey, whatever the type T is, it would be nice to have an easy way of specifying a stronger alignment constraint. This is particularly useful to allocate for example buffers of uint8_t on 16-byte or 64-byte boundaries for performance reasons.

Regards,
Étienne

This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization.