[type_traits] alignment_of_test problem in Intel Linux
The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <: I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp #define ALIGNOF(x) align_calc<x>::get() as #define ALIGNOF(x) align_calc< x>::get() (note the extra blank). OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz writes:
The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <:
I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp
#define ALIGNOF(x) align_calc<x>::get()
as
#define ALIGNOF(x) align_calc< x>::get()
(note the extra blank). OK to commit?
Yes, please! (It's a bug in the compiler/preprocessor, of course). -- Aleksey Gurtovoy MetaCommunications Engineering
On 9/14/04 4:24 AM, "Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
Joaquín Mª López Muñoz writes:
The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <:
I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp
#define ALIGNOF(x) align_calc<x>::get()
as
#define ALIGNOF(x) align_calc< x>::get()
(note the extra blank). OK to commit?
I think the other side of "x" needs space protection too, from ":>" and ">>". So the solution could be changed (again) to: #define ALIGNOF(x) align_calc< x >::get() BTW, can parentheses be used around "x" as better protection instead? Or does that work only for objects?
Yes, please! (It's a bug in the compiler/preprocessor, of course).
Not necessarily. It depends on where digraph expansion is supposed to occur relative to macro expansion. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daryle Walker
Yes, please! (It's a bug in the compiler/preprocessor, of course).
Not necessarily. It depends on where digraph expansion is supposed to occur relative to macro expansion.
The above represents a preprocessor bug (it is operating on text instead of on preprocessing tokens). Digraphs are separate preprocessing tokens (just like their "regular" equivalents)--see the grammar production "preprocessing-op-or-punc". E.g. %:define ABC // should be fine Regards, Paul Mensonides
Daryle Walker writes:
On 9/14/04 4:24 AM, "Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
Joaquín Mª López Muñoz writes:
The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <:
I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp
#define ALIGNOF(x) align_calc<x>::get()
as
#define ALIGNOF(x) align_calc< x>::get()
(note the extra blank). OK to commit?
I think the other side of "x" needs space protection too, from ":>" and ">>".
This could never occur in this particular case (see the code), but in general, yes.
So the solution could be changed (again) to:
#define ALIGNOF(x) align_calc< x >::get()
BTW, can parentheses be used around "x" as better protection instead? Or does that work only for objects?
The latter.
Yes, please! (It's a bug in the compiler/preprocessor, of course).
Not necessarily.
Sure it is.
It depends on where digraph expansion is supposed to occur relative to macro expansion.
During tokenization, which happens before the macro expansion; see the standard. -- Aleksey Gurtovoy MetaCommunications Engineering
The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <:
I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp
#define ALIGNOF(x) align_calc<x>::get()
as
#define ALIGNOF(x) align_calc< x>::get()
(note the extra blank). OK to commit?
Yes please, thanks, John.
participants (5)
-
Aleksey Gurtovoy -
Daryle Walker -
Joaquín Mª López Muñoz -
John Maddock -
Paul Mensonides