> [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey

> Exactly. But the expanded <some_class<...>> is the result of the 
> preprocessor, so IIRC the two >'s are treated as two tokens, 
> not as one, 
> because they weren't glued together with ##. Also, the GCC 
> preprocessor 
> expands the above to
> 
> < some_class<...> >
> 
> and I'm pretty sure that the rules for inserting spaces are exactly 
> defined and there is not much room for interpretation. If the GCC is 
> correct to insert spaces, then the patch is a work-around for 
> a compiler 
> (here: preprocessor) bug. So, what is the correct behaviour here?

It isn't technically supposed to insert spaces, but it is supposed to
treat them as two consecutive tokens with no whitespace separation--same
as "+-".

You can get this situation similar to the following:

#define MACRO(a) a>

MACRO(>)

The result is:

'>' '>'

Not:

'>' ' ' '>'

And definitely not:

'>>'

E.g. they are distinct, but a preprocessor shouldn't be adding
whitespace *unless* it is producing a text stream which is going to be
re-tokenized by a separate preprocessor/compiler pass.  In that case, it
*must* add the whitespace to prevent retokenization that yields
different tokens.

Regards,
Paul Mensonides

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to