Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: f***ing comments -- another pitfall to avoid Message-ID: Date: 4 Jun 90 03:03:51 GMT References: <31914@sparkyfs.istc.sri.com> <75.UUL1.3#5109@pantor.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 30 In-reply-to: richard@pantor.UUCP's message of 31 May 90 14:43:19 GMT In article <75.UUL1.3#5109@pantor.UUCP> richard@pantor.UUCP (Richard Sargent) writes: > From: mckenney@sparkyfs.istc.sri.com (Paul Mckenney) > Message-ID: <31914@sparkyfs.istc.sri.com> > ... 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. What's extremist about insisting that the comment construct of a language have no adverse behavior on the rest of the language (isn't that the purpose of the comment - provide documentation, but do not affect compilation?). Sure its obvious that the hangover from C (/* ... */) will have the desired affect, but that doesn't invalidate the problem with '//' with regards to macros. Let's not start flame wars over the differences between '/* ... */' and '//'. ;-) -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"