mckenney@sparkyfs.istc.sri.com (Paul Mckenney) (05/26/90)
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: ------------------------------------------------------------------------ # 1 "commentmacro.cc" a test This is ------------------------------------------------------------------------ Here, the ``//'' has apparently eaten the backslash, thus prematurely terminating the comment. I would prefer to see the ``//'' comment operate up to (but not including) the next newline or the next backslash that is immediately followed by a newline (whichever comes first). This would yield the more intuitive result: ------------------------------------------------------------------------ # 1 "commentmacro1.cc" This is a test ------------------------------------------------------------------------ I guess that the moral of this story is that one should always use the ``/**/'' style comments inside of macro definitions, at least until the ``//'' comments behave more intuitively in mainstream implementations... Thanx, Paul
steve@taumet.COM (Stephen Clamage) (05/27/90)
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
mckenney@sparkyfs.istc.sri.com (Paul Mckenney) (05/29/90)
In article <219@taumet.COM> steve@taumet.UUCP (Stephen Clamage) writes: >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. I definitely agree that C++ features should be used in preference to preprocessor features where feasible. Unfortunately, my application would require templates in the case where I ran into this problem (and I am not absolutely positive that templates would be sufficient; I am not clear on the interaction between templates and inheritance). 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. Thanx, Paul PS. A (small) fragment of my big, ugly macro follows to motivate my desired behavior of comments in macro definitions. Processing ``//'' comments after deleting escaped newlines makes such comments almost useless in multiline macros. ------------------------------------------------------------------------ #define DEFINE_notifier(BASECLASS, MODIFIER) \ \ ... lots of stuff deleted ... \ \ class notifier_##BASECLASS##_##MODIFIER##_class; \ inline int notifier_##BASECLASS##_##MODIFIER##_class::add_recipient( \ notifiee_##BASECLASS##_##MODIFIER##_class &x \ ) \ \ { \ \ if (x.next != NULL) \ { \ \ // Added to the list twice, so die. \ \ return (0); \ } \ \ // Need mutual exclusion with del_recipient here for the \ // multiprocessor case. \ \ x.next = list; \ list = &x; \ return (1); \ } \ \ ... lots more stuff deleted ...
shankar@hpclscu.HP.COM (Shankar Unni) (05/31/90)
> 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? 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 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 \<newline>s). - process comments (i.e. strip out /**/ and // comments) ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
davidc@vlsisj.VLSI.COM (David Chapman) (05/31/90)
In article <31914@sparkyfs.istc.sri.com> mckenney@perth.itstd.sri.com.UUCP (Paul E. McKenney) 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. > >(example macro follows:) >#define DEFINE_notifier(BASECLASS, MODIFIER) \ >... lots of stuff deleted ... \ >class notifier_##BASECLASS##_##MODIFIER##_class; \ >inline int notifier_##BASECLASS##_##MODIFIER##_class::add_recipient( \ > notifiee_##BASECLASS##_##MODIFIER##_class &x \ >... > if (x.next != NULL) \ > { \ > // Added to the list twice, so die. \ >... 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. 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. -- David Chapman {known world}!decwrl!vlsisj!fndry!davidc vlsisj!fndry!davidc@decwrl.dec.com
richard@pantor.UUCP (Richard Sargent) (05/31/90)
> 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
davidm@uunet.UU.NET (David S. Masterson) (06/04/90)
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!"
jamiller@hpcupt1.HP.COM (Jim Miller) (06/05/90)
IMO, "#define"'s are text processing, not language. Putting language
specific stuff into the text processor will only confuse the issue.
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!)
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 ...
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.
jim - consistency is the hob-goblin of little minds - miller
The place where I work doesn't even know I have opinions,
let alone approve of them.mckenney@itstd.sri.com (Paul E. McKenney) (06/08/90)
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 \<newline>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.
harp@cadillac.CAD.MCC.COM (Christopher North-Keys) (06/12/90)
There's a perfectly quaint discussion going on about using comments in the
middle of long hairy macros. The problem appears to be that for some supposed
reason of elegance the "// ... \n" comment style should work as well as the
"/* ... */" style.
Now let's get this straight; these nice folk want to put a
comment-to-end-of-line in the *middle* of a single-line macro? And because
they can't do it they want a provision that screws escaped-newline parsing
all to [suitable nether plane] and back?
This is not elegant, clear, or advisable. It is also completely unnecessary
as has already been noted, as the "/* ... */" does *exactly* the function
specified.
Let's put it this way (and if you have to think to hard you've given the
prime example of how this "//-comment within macro" concept is *not* worth
the time):
Let's suppose we have, despite all the nice things in C++ that
tend to make them less necessary, written a 50-line preprocessor
macro. We've gone ahead and butchered our cpp to handle the
special case of terminating //-comments by converting "// ... \n"
to "/* ... */" ONLY WITHIN the "#define ... \n" construct. Well,
wait, it's not working because all the escaped newlines are getting
stripped before the macros and comments are checked. Fine. We'll
put the comment stripping before the escaped-newline strip, and
do the substitution in that phase. Let's try it...sytax error?!?!
Oh, look here, some fool using escaped newlines within a //-comment...
I though they weren't supposed to do that, that's not what the //
form was for, they've already the block "/* ... */" comments we
all know and love, and look how much additional work it'll take to
put in a subcheck for stripping escaped newlines with comments NOT
withing macros...
Heavy, rasping sarcasm. No smiley. Get a life.
Putting in the kind of "feature" they're talking about is simply abuse, and
a bad idea. Offhanded preprocessor over-complication usually leads to bugs,
incompatibility, and ambiguity. C++ already has certain syntactic quirks
without our putting contributing non-intuitive (YES "NON-INTUITIVE") constructs
in the preprocessor. I vote against.
#define TRUE \
// Disclaimer: this are my opinions, not necessarily that of my employers. \\
Any sarcasm is directed at the concepts I find offensive, not the \\
people who came up with them, at least not as much :-) \
0
This should work too, right? Shouldn't we add it? Let's see, a check for
escaped-newline-escapes within a "// ... \n" comment with a macro...where
should we put it, this code's starting to look kinda complex...I though
preprocessors were supposed to be simple, anyway.
Hey, look. The value's wrong anyway. Lets just comment all the crud out
of it and fix it...
#define FALSE /* TRUE \
// Disclaimer: this are my opinions, not necessarily that of my employers. \\
Any sarcasm is directed at the concepts I find offensive, not the \\
people who came up with them, at least not as much :-) \
*/ 0
Umm, shouldn't this work too...?
--
--Christopher Alexander North-Keys----/\--------------------------------------
Co-founder Group Talisman / \/\ ^*^ Harp[@Mcc.Com]
[*my* opinions] / \ \ Associate Systems Analyst
--------------------------Microelectronics & Computer Technology Corporation--davidm@uunet.UU.NET (David S. Masterson) (06/14/90)
In article <8878@cadillac.CAD.MCC.COM> harp@cadillac.CAD.MCC.COM (Christopher North-Keys) writes: There's a perfectly quaint discussion going on about using comments in the middle of long hairy macros. The problem appears to be that for some supposed reason of elegance the "// ... \n" comment style should work as well as the "/* ... */" style. What's wrong with having a consistent comment interface inside macros or out. Nothing in the forgoing discussion requires special processing of "//" comments for just macros. The processing should occur everywhere! Now let's get this straight; these nice folk want to put a comment-to-end-of-line in the *middle* of a single-line macro? And because they can't do it they want a provision that screws escaped-newline parsing all to [suitable nether plane] and back? This is not elegant, clear, or advisable. It is also completely unnecessary as has already been noted, as the "/* ... */" does *exactly* the function specified. The desired effect is that "//" comments end at an escaped newline regardless whether the comment is within a macro or not. "/* ... */" does handle the problem, but that was never the question! #define TRUE \ // Disclaimer: this are my opinions, not necessarily that of my \\ employers. Any sarcasm is directed at the concepts I find offensive, \\ not the people who came up with them, at least not as much :-) \ 0 This should work too, right? No, but this should: #define TRUE \ // Disclaimer: these are my opinions, not necessarily that of my \ // employers. Any sarcasm directed at people who miss obvious concepts \ // is mostly in fun. :-) \ 0 Hey, look. The value's wrong anyway. Lets just comment all the crud out of it and fix it... #define FALSE /* TRUE \ // Disclaimer: this are my opinions, not necessarily that of my \\ employers. Any sarcasm is directed at the concepts I find offensive, \\ not the people who came up with them, at least not as much :-) \ */ 0 Umm, shouldn't this work too...? Again no, but this should: #define FALSE /* TRUE \ // Disclaimer: these are my opinions, not necessarily that of my \ // employers. Any sarcasm directed at people who miss obvious concepts \ // is mostly in fun. :-) \ */ 0 Conceptually, it works for me! ;-) -- =================================================================== 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!"
mckenney@sparkyfs.istc.sri.com (Paul Mckenney) (06/14/90)
In article <8878@cadillac.CAD.MCC.COM> harp%cad@MCC.COM (Christopher North-Keys) writes: >There's a perfectly quaint discussion going on about using comments in the >middle of long hairy macros. The problem appears to be that for some supposed >reason of elegance the "// ... \n" comment style should work as well as the >"/* ... */" style. >[ . . . ] >This is not elegant, clear, or advisable. It is also completely unnecessary >as has already been noted, as the "/* ... */" does *exactly* the function >specified. From your response and from some private responses that I have received, I obviously failed to explain my proposal sufficiently. Please accept my apologies and allow me to try again. I will then show how my proposal handles the examples that you presented. First, just what is ``intuitive''? For ``//'' comments, this means that such a comment may be located by looking only at the lexical context and that its effect will never extend beyond the end of a physical source line. More precisely, the effect of a ``//'' comments ends with the character preceding the next newline or escaped newline. >Let's put it this way (and if you have to think to hard you've given the >prime example of how this "//-comment within macro" concept is *not* worth >the time): The examples are easy if you are using the definition above, again, please accept my apologies for not making myself clear previously. > Let's suppose we have, despite all the nice things in C++ that > tend to make them less necessary, written a 50-line preprocessor > macro. We've gone ahead and butchered our cpp to handle the > special case of terminating //-comments by converting "// ... \n" > to "/* ... */" ONLY WITHIN the "#define ... \n" construct. Well, The ``//'' comments work identically inside and outside of #defines, so this is not a problem. > wait, it's not working because all the escaped newlines are getting > stripped before the macros and comments are checked. Fine. We'll The ``//'' comment ends immediately -before- the next escaped newline or the next newline, whichever comes first, so this is also not a problem. > put the comment stripping before the escaped-newline strip, and > do the substitution in that phase. Let's try it...sytax error?!?! > Oh, look here, some fool using escaped newlines within a //-comment... An escaped newline terminates a ``//'' comment, thus it is not possible to use an escaped newline within a comment. Again, no problem. > I though they weren't supposed to do that, that's not what the // > form was for, they've already the block "/* ... */" comments we > all know and love, and look how much additional work it'll take to > put in a subcheck for stripping escaped newlines with comments NOT > withing macros... Both ``//''-comments as I have proposed them and escaped newlines work the same both inside and outside of macros, so this is not a problem. >Heavy, rasping sarcasm. No smiley. Get a life. Thank you very much for the kind offer, but I already have a life :-). >#define TRUE \ > // Disclaimer: this are my opinions, not necessarily that of my employers. \\ > Any sarcasm is directed at the concepts I find offensive, not the \\ > people who came up with them, at least not as much :-) \ > 0 The ``//''-comment is terminated by the newline. Note that the line beginning with ``// Disclaimer'' does -not- have an escaped newline, since the escape is itself escaped. The macro thus consists entirely of whitespace (once the ``//'' comment is removed). Suppose the double backslashes in the example are replaced by single backslashes: #define TRUE \ // Disclaimer: this are my opinions, not necessarily that of my employers. \ Any sarcasm is directed at the concepts I find offensive, not the \ people who came up with them, at least not as much :-) \ 0 The macro value is then ``Any sarcasm is . . . not as much :-) 0'', since the ``//''-comment extends only up to (but no including) then escaped newline. >Hey, look. The value's wrong anyway. Lets just comment all the crud out >of it and fix it... >#define FALSE /* TRUE \ > // Disclaimer: this are my opinions, not necessarily that of my employers. \\ > Any sarcasm is directed at the concepts I find offensive, not the \\ > people who came up with them, at least not as much :-) \ > */ 0 In this example, there is no ``//'' comment, since the ``//'' is contained within the ``/**/'' comment. In other words, you cannot nest ``//'' comments within ``/**/'' comments any more than you can nest one ``/**/'' comment within another. >Umm, shouldn't this work too...? I would suspect that different implementations might react differently to a macro that ends in the middle of a comment (note the double backslash). Any ANSI-C language lawyers care to give an opinion on this one? Thanx, Paul