This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Preprocessor Problems
- To: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Subject: Re: Preprocessor Problems
- From: Dave Brolley <brolley at redhat dot com>
- Date: Tue, 23 Jan 2001 15:32:00 -0500
- CC: Alexy Khrabrov <alexy dot khrabrov at setup dot org>, gcc-bugs at gcc dot gnu dot org, John Pedretti <pedretti at roguewave dot com>, Martin Sebor <sebor at roguewave dot com>, Neil Booth <neilb at earthling dot net>
- References: <14957.50528.659741.802398@roll.badbox.com> <20010123183054.C6595@daikokuya.demon.co.uk>
Generally, this kind of misuse is an attempt to delay the pre-expansion
of a macro argument. This can be necessary if the argument is a macro
name intended to be pasted at the next nesting level. There are 3
portable solutions that I see:
1) Move the pasting out of ETEMPLATE to within the invocation of ETEMPLATE
2) Define the macro named in the argument as function-like so that it
doesn't get pre-expanded before being passed to ETEMPLATE
3) pass the name in pieces and paste it in the invocation of ETEMPLATE
Solution 3) would require changes to the way these macros are used and
it appears that this is a well known library of macros.
In any case, Neil is right. The usage below is unportable and gcc is
correct to warn about it.
Dave
Neil Booth wrote:
> Alexy Khrabrov wrote:-
> Content-Description: message body and .signature
>
>> ETEMPLATE(##ctypes) class name; \
>> ETEMPLATE(##ctypes) \
>
>
> This kind of stuff is not portable. Why do you need the ##? Just
> remove it, and probably everywhere else it is complained about. You
> cannot paste anything with a '('; shame on other preprocessors for not
> telling you so.
>
> Neil.
>
>