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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19163
Uh, yeah, it compiles...
but watch out for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
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
