Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!geac!becker!pantor!richard
From: richard@pantor.UUCP (Richard Sargent)
Newsgroups: comp.lang.c++
Subject: Re: f***ing comments -- another pitfall to avoid
Message-ID: <75.UUL1.3#5109@pantor.UUCP>
Date: 31 May 90 14:43:19 GMT
References: <31914@sparkyfs.istc.sri.com>
Organization: Pansophic Systems Inc, Graphics Product Company
Lines: 34

> From: mckenney@sparkyfs.istc.sri.com (Paul Mckenney)
> Message-ID: <31914@sparkyfs.istc.sri.com>
...
> In article <219@taumet.COM> steve@taumet.UUCP (Stephen Clamage) writes:
> >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.
>  
...
> 
> I sympathize with your interpretation of how commentmacro should
> be expanded, but I dislike the results, to say the least!  The effect
> is that the first ``//'' comment encountered throws the rest of the
> macro definition away.  If ``//'' comments are to be useful inside
> of macros, they should delete the text up to, but not including, the
> first occurance of either a newline or a backslash immediately preceding
> a newline.
> 


This is crazy... If you want to limit the range of effect that
a comment has, use the fully delimited comment: /* ... */

C++ has not invalidated this construct.

This is just another example of extremism causing problems.
Use the right tools for every job and you'll find things
generally go better.

Don't try to change the language just because you insist on
doing things poorly. Use the language properly.

Richard Sargent                   Internet: richard@pantor.UUCP
Systems Analyst                   UUCP:     ...!mnetor!becker!pantor!richard