Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!sparkyfs!itstd.sri.com!mckenney From: mckenney@itstd.sri.com (Paul E. McKenney) Newsgroups: comp.lang.c++ Subject: Re: f***ing comments -- another pitfall to avoid Message-ID: <32127@sparkyfs.istc.sri.com> Date: 8 Jun 90 00:02:56 GMT Sender: mckenney@sparkyfs.istc.sri.com Reply-To: mckenney@itstd.sri.com (Paul E. McKenney) Organization: SRI International, Menlo Park, CA 94025 Lines: 142 Thought I'd put my response to several articles on this topic into one message . . . Thanx, Paul ------------------------------------------------------------------------ In article <15587@vlsisj.VLSI.COM> davidc@vlsisj.VLSI.COM (David Chapman) writes: >In article <31914@sparkyfs.istc.sri.com> mckenney@perth.itstd.sri.com.UUCP (Paul E. McKenney) writes: [ugly macro definition deleted] >Examples like this remind me why I hate multi-line macros so much, along >with macros that try to do anything more than a simple expression. They're >extremely hard to understand and debug. (We've had flamewars here about >them, so I won't say any more.) >My solutions would be: a) comment an example expansion of the macro, and >leave the macro itself without any comments (would make the macro easier to >read as well), or b) don't use macros at all and just write the function >explicitly for each class type. If you think that this excerpt was bad, just be glad that I didn't post the macro in its entirety! :-) I fully agree with your option (a); in fact, the file in which the fragment appears has a header comment that documents how the macro is to be used. I did not include the header comment in my posting in an attempt to save net bandwidth; in retrospect, this effort was entirely counterproductive! I have used your option (b) in the past, it is especially useful where the macros would be small and would have lots of parameters. However, your option (b) is not reasonable in this particular case, as the macro expands to two class definitions with several member functions each. There is not much chance that I would get all of the functions right all of the time! I considered writing a small program to generate the functions for me, but decided that the preprocessor did the job just fine. However, I have used your option (b) for smaller functions. >I can see the need for templates as a language feature, but in its absence >you need to worry about code clarity and ease of maintenance. I think that >very complicated macros such as this fail both tests. I certainly will be very happy when templates arrive at a compiler near me! Until then, very complicated macros (and g++lib's genclass) will occasionally be needed. --------------------------------------------------------------------------- In article <58170022@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >> 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 does not really conflict with the ANSI C standard, since ANSI C >> does not have ``//'' comments. C++ would of course need to define >> the interaction explicitly -- the current smorgasborg of behaviors >> is no doubt in part due to the lack of explicit definition. > >And I sympathise with your "DWIM" interpretation. > >But remember: a macro definition is technically ONE line. If you embed a >"//" comment in there, tough luck: you just lost the rest of the line. >Would you embed a "//" comment in the middle of a function call list, like >so: > foo (x // comment, y, z)? >What is the difference between this, and what you are trying to do with >your macro? The difference is that the above statement is contained on one physical line of source code, while my macro spans many lines. >Remember, there is a place for /**/ comments and a place for // comments. >The "old-style" comments are by no means second-class in C: they are >intended to be used in exactly the situation that you describe: > #define longmacro line /* comment */ \ > line /* comment */ \ > line /* comment */ The ``old-style'' comments used to be the -only- comment style in C. I used it for many more years than I care to admit, but that doesn't mean that I am opposed to newer and, IMHO, better approaches. >The most logical (and in my opinion, correct) way to handle macro >definitions is to do it as follows: > - pull in everything upto a unescaped newline (deleting all \s). > - process comments (i.e. strip out /**/ and // comments) I agree that this might be very logical from the point of view of the compiler implementor. However, the whole reason for introducing the ``//'' comments in the first place was to make the code easier to read. I feel that the current implementations fall somewhat short of that goal. ------------------------------------------------------------------------ In article <7050014@hpcupt1.HP.COM> jamiller@hpcupt1.HP.COM (Jim Miller) writes: >If in normal C++ you write: > a += b; // comment \ > x += y; > z += w; >the resultant code would be: > a += b; > z += w; >EXACTLY like what happened in the #define (how about that!) Thank you for providing me with another example of the bad effects of the current implementations of ``//'' comments. :-) I will admit that my eyes are not what they could be, but I suspect that quite a few people might miss that little trailing backslash that gobbles up the following line. Of course, one could run the code through the preprocessor to see the problem. I would prefer that the ``//'' comments operate so that I could rely on the visual cue that it provides in the original source code. Your example gives an excellent demonstration of how I must painstakingly examine the end of each line containing such a comment to see if the next physical line is also commented out. >Changing "#define" behavior then will make it impossible to understand what >the result of a macro will be (now, do I have yet another special case or >is this one of those few standard cases :-). >I know, I know, just this one little change, no more ... I feel that changing the ``//'' comment behavior will make it -easier- to understand what the result of a macro will be. >In addition, people get are using the pre-processor for other things >than C and C++. Nasty people, I know, but changing the pre-processor >will make it unusable to many who are using it in this evil way. I confess to having abused the preprocessor in exactly this way myself, and am therefore very sympathetic to your concern over changing the preprocessor in any way, no matter how slight. However, please note that the recent addition of ``//'' comments was exactly such a change. Thus, I am not asking for a new change; I am proposing a fix to a previous change.