incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: question about aligned_storage
Date Thu, 26 Jun 2008 19:11:30 GMT
Travis Vitek wrote:
> Martin Sebor wrote:
>> Travis Vitek wrote:
> [...]
>>> The only functionality I have available 
>>> to me for
>>> doing alignment (on the tested platforms) is __declspec(align(#)) on
>>> Microsoft and __attribute__ ((aligned(#))) on gcc-4.3. Both of these
>>> support functions require that the alignment value be a power of two.
>>> The Microsoft compiler has the 8192 limit.
>> An upper limit is acceptable (it should be mentioned in one of
>> the appendices to the spec). I'm more interested in alignments
>> that aren't powers of 2. It's not clear to me why restricting
>> the template to powers of 2 is okay or why it's difficult not
>> to support all of them up to the limit.
> I'm not saying it is okay to limit them to powers of two, I'm just
> saying that non-power of two values won't work on the platforms that are
> currently supported. The aligned attribute on gcc pukes if you use
> non-power-of-two alignment values.

That's gcc's problem, not ours :) Code involving non-powers of 2
will fail to compile either way, so unless we think that rounding
the request up to the next power of two is the right thing to do
there's nothing we can do about it.

> I could implement the specializations of the helper for all possible
> values up to the upper limit and then let the compiler puke when it
> can't honor the alignment that was requested. It is not 'difficult' to
> do this, I just don't see it as useful because I can't test them until I
> have at least one compier that supports the ability to do
> non-power-of-two alignments.

That was another question I was going to ask although I think I know
the answer already: the specialization is only necessary for "crappy
compilers" ;-) that require N to be a literal in
__attribute__((aligned(N))), right? If so, I suggest providing the
specializations only for these, shall we say, "limited" compilers
and defining the primary template using the non-type template
parameter N for the rest.

>>> The draft shows a 'typical implementation' of 
>>> aligned_storage that uses the new alignas keyword,
>>> but alignas doesn't appear to be supported
>>> anywhere.
>> That's probably because they didn't want to favor any existing
>> implementation over others.
> I don't see this as a problem with the standard not wanting to favor one
> implementation over another, it is a problem because no current
> implementation supports the new keyword.

That might have been the point: use a made up keyword that doesn't
exist on any implementation so as not to suggest that one should
be preferred over the others. (Just guessing.)

>>> The following code is very similar to that typical
>>> implementation, but it does not compile because value passed to the
>>> aligned attribute has to be a literal, not a constant expression.
>> That's what you for using a crappy compiler ;-) It compiles
>> with gcc. See
> Uh, yeah, it compiles...
>> but watch out for:
> but it is utterly useless because of this bug. You can't use the nested
> aligned type. Talk about crappy compilers.

It isn't completely useless because the attribute can successfully
be applied to data members with the same result:

     template <int N>
     struct A {
         struct S {
             short f[3]; __attribute__ ((aligned (N)));

>> We should open an enhancement request with Microsoft.
> I'll do that.
>> Martin

View raw message