Path: utzoo!attcan!uunet!taumet!steve
From: steve@taumet.COM (Stephen Clamage)
Newsgroups: comp.lang.c++
Subject: Re: f***ing comments -- another pitfall to avoid
Message-ID: <219@taumet.COM>
Date: 26 May 90 17:35:48 GMT
References: <1504@trlluna.trl.oz> <69.UUL1.3#5109@pantor.UUCP> <54683@microsoft.UUCP> <0682@sheol.UUCP> <54781@microsoft.UUCP> <31891@sparkyfs.istc.sri.com>
Reply-To: steve@taumet.UUCP (Stephen Clamage)
Organization: Taumetric Corporation, San Diego
Lines: 36

In article <31891@sparkyfs.istc.sri.com> mckenney@.itstd.sri.com (Paul E. McKenney) writes:
>Even if you have a preprocessor that knows about C++ comments, one must
>be careful...
>Consider the following:
>------------------------------------------------------------------------
>	#define commentmacro \
>			This is // (we interrupt this macro with a comment) \
>			a test
>	commentmacro
>------------------------------------------------------------------------
>Doing ``g++ -E'' yields:
> [ something unexpected ]

Well, we have an example of preprocessing that follows neither the
ANSI C standard nor the C++ Reference Manual (latest edition).  According
to both, ANSI section 2.1.1.2 "Translation phases" and C++RM section 16.1
"Phases of preprocessing", the escaped newline is deleted, and the
following line is concatenated.  *After* that, tokenizing begins.

Thus the correct expansion for commentmacro is
	This is

Your main point is well-taken:  Do be careful with comments in macros,
at least until we get consistently correct behavior in C++ implementations.
The only safe thing is not to put comments in macros at all.

On the plus side (or ++ side), macros are not much needed in C++:
Instead of:	#define MAX 10
use:		const int MAX = 10;
Instead of:	#define foo(bar) expression
use:		inline int foo(int bar) { return expression; }

The C++ alternatives are safer, in that they are properly scoped.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com