In <4ok5qo$192a@news.rchland.ibm.com> Bill Seurer (seurer@rchland.ibm.com) wrote:
[....]
> |> In my experience, among the subtlest and most difficult-to-find errors
> |> involve missing comment terminators. I once worked on a program that had
> |> been in use for years, yet I accidently noticed a missing comment terminator
> |> that meant an intended line of code had never been compiled into the program.
> |> It seems to me that nested comments make this situation worse, not better.
> |> If you avoid "/*" comments in favor of "//" comments, you elminate the problem.
>
> If this is a problem then use an editor that visually marks commented
> areas.  The one I use here at work uses an italic font for comments and
> it has been ages since I messed up a comment.

In fact, this is another thing (in addition to verbosity) that I dislike in
the '#if 0...#endif' approach - smart editors won't highlight these
'comments' properly (unless you build a full C++ preprocessor into the
editor).

              Bye                            Genie
--
-----------------------------------------------------------------------
Eugene V. Radchenko              Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290
Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
                         Moscow State University, 119899 Moscow, Russia
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    Axiom:        Any non-trivial program contains some bugs
    Corollary:    If a program has no bugs, it is useless




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi people!
I wonder what the point of disallowing nested /* */ comments is?
Despite being illogical (programmers like balanced delimeters, after all),
it can also cause errors (suppose I comment out the inclusion of some
header while the author of the header was being nice and put comments in it
as well?).
Also, the price of nested comments is negligible compared to all other
things the compiler has to track (and decent compilers has in fact had an
option of nested comments for years).

           Cheers                        Genie

--
-----------------------------------------------------------------------
Eugene V. Radchenko              Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290
Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
                         Moscow State University, 119899 Moscow, Russia
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    Axiom:        Any non-trivial program contains some bugs
    Corollary:    If a program has no bugs, it is useless
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:

>Hi people!
>I wonder what the point of disallowing nested /* */ comments is?
>Despite being illogical (programmers like balanced delimeters, after all),
>it can also cause errors (suppose I comment out the inclusion of some
>header while the author of the header was being nice and put comments in it
>as well?).

Allowing them would cause as many problems as it would solves.
Consider the following example:

 /**** don't use this code!

 cout << "*/";

 ****/

Furthermore, there is already a way to comment out code in C and C++
that can be nested, and doesn't run into problems like the above:

 #if 0 // don't use this code!

 cout << "*/";

 #endif

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article AGRAjRr0u3@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
>Hi people!
>I wonder what the point of disallowing nested /* */ comments is?
>Despite being illogical (programmers like balanced delimeters, after all),
>it can also cause errors (suppose I comment out the inclusion of some
>header while the author of the header was being nice and put comments in it
>as well?).
>Also, the price of nested comments is negligible compared to all other
>things the compiler has to track (and decent compilers has in fact had an
>option of nested comments for years).

I disagree that nested comments serve any useful purpose given the available
alternatives in C++. I also disagree that the lack of nested comments can
cause errors. I would argue the other way: nested comments are error-prone
and result in code that is hard to maintain.

Your example of commenting out inclusion of a header is a non-issue. For example:
 /*
 #include "f1.h"
 */
 /* #include "f2.h" */
 // #include "f3.h"
In all three cases, the #include is ignored, so it doesn't matter what
the header files contain. No inclusion takes place.

With non-nested comments, you can easily and unconditionally find the end
of a comment with any text editor: it is at the next "*/", no matter what.
With nested comments, the procedure is more difficult. As with finding a
balancing ")" or "}", you would want some special help from the text editor.

In my experience, among the subtlest and most difficult-to-find errors
involve missing comment terminators. I once worked on a program that had
been in use for years, yet I accidently noticed a missing comment terminator
that meant an intended line of code had never been compiled into the program.
It seems to me that nested comments make this situation worse, not better.
If you avoid "/*" comments in favor of "//" comments, you elminate the problem.

If you want to comment out several lines of code in C++, you have three
options:

1. Insert a "//" at the start of each line.
2. Insert a "/*" at the start of each line and add "/**/" after the last line --
   but this won't work if a line contains an embedded comment. (I suppose that
   is your complaint.)
3. Insert "#if 0" ahead of the first line and "#endif" after the last line.

Options 1 and 3 are perfectly safe. Option 3 strikes me as equivalent to
using "/*" and "*/", and the #if/#endif pairs do nest.

If you adopt a coding style whereby you only use "//" comments, you can comment
out any section of code with "/*" and "*/".
---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ofm6g$4b4@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.sun.com> wrote:
>I disagree that nested comments serve any useful purpose given the available
>alternatives in C++. I also disagree that the lack of nested comments can
>cause errors. I would argue the other way: nested comments are error-prone
>and result in code that is hard to maintain.

In general I go along with this; and indeed any compiler which allows comments
to nest is not a C++ compiler, but:

>In my experience, among the subtlest and most difficult-to-find errors
>involve missing comment terminators. I once worked on a program that had
>been in use for years, yet I accidently noticed a missing comment terminator
>that meant an intended line of code had never been compiled into the program.
>It seems to me that nested comments make this situation worse, not better.

I think this example runs counter to your argument; a compiler supporting
nested comments would easily pick up such an error when it found that one of
the comments was never terminated. Since C++ comments don't nest, C++
compilers can't usually pick up this particular error because it's likely that
there will be another comment later on which will terminate our wayward
comment. It's not likely to do what the programmer expected though.

>3. Insert "#if 0" ahead of the first line and "#endif" after the last line.

This solution has the disadvantage that the code between the "#if 0" and
"#endif" must still consist of valid preprocessor tokens, so you can't use it
to comment out arbitrary text.

Regards,
Graham
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Graham Stoney wrote:
> In article <4ofm6g$4b4@engnews1.Eng.Sun.COM>,
> Steve Clamage <clamage@Eng.sun.com> wrote:
> >In my experience, among the subtlest and most difficult-to-find errors
> >involve missing comment terminators. I once worked on a program that had
> >been in use for years, yet I accidently noticed a missing comment terminator
> >that meant an intended line of code had never been compiled into the program.
> >It seems to me that nested comments make this situation worse, not better.
>
> I think this example runs counter to your argument; a compiler supporting
> nested comments would easily pick up such an error when it found that one of
> the comments was never terminated.

And on what line would it flag the error?  On the last line of the source file.
Not very useful.

On the other hand, a compiler that rejects nested comments could warn if it saw
a start-comment-token while still within a comment.  That will certainly be MUCH
closer to where the end-comment-token is missing.

> Since C++ comments don't nest, C++
> compilers can't usually pick up this particular error because it's likely that
> there will be another comment later on which will terminate our wayward
> comment. It's not likely to do what the programmer expected though.

True enough.  That's why it's a good idea to warn if a /* appears within a
/*-style comment.  Obviously, the warning level should be very low, and should
not cause processing to stop or a failing status to be returned.

> >3. Insert "#if 0" ahead of the first line and "#endif" after the last line.
>
> This solution has the disadvantage that the code between the "#if 0" and
> "#endif" must still consist of valid preprocessor tokens, so you can't use it
> to comment out arbitrary text.

Exactly what kind of garbage are you trying to comment out???  It could not have
been valid code before you commented it out!

By the way, instead of "#if 0", I prefer "#if defined(CAUSE_XXX_UNDESIRED_BEHAVIOR)".
That allows you to selectively re-enable code easily to determine if a particular
problem has been incorrectly fixed or whether the commented out code is also
responsible for some other problem.  If it's worth commenting out rather than
outright deletion, then it's worth making easy to reenable.

--
I protest!  I am *NOT* a Merry Man!
Dave Toland       Platinum Solutions, Inc.    det@platsol.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ofm6g$4b4@engnews1.Eng.Sun.COM>, clamage@Eng.sun.com (Steve Clamage) writes:
|>
|> I disagree that nested comments serve any useful purpose given the available
|> alternatives in C++. I also disagree that the lack of nested comments can
|> cause errors. I would argue the other way: nested comments are error-prone
|> and result in code that is hard to maintain.

I use other languages that allow nested comments and they do not cause
any problems.  They DO serve a useful purpose which the C++ alternatives
only MOSTLY cover.  Quite frankly it is rare to encounter them in
practice.  As for having them or not causing errors, well, I haven't seen
any errors in my non-C++ code because of having them nor errors in my
C++ code for not having them (see below).

|> Your example of commenting out inclusion of a header is a non-issue. For example:
|>  /*
|>  #include "f1.h"
|>  */
|>  /* #include "f2.h" */
|>  // #include "f3.h"
|> In all three cases, the #include is ignored, so it doesn't matter what
|> the header files contain. No inclusion takes place.

Yup.

|> With non-nested comments, you can easily and unconditionally find the end
|> of a comment with any text editor: it is at the next "*/", no matter what.
|> With nested comments, the procedure is more difficult. As with finding a
|> balancing ")" or "}", you would want some special help from the text editor.

You are sort of arguing from both sides here Steve.  If balancing nested
comments is so hard why can we nest parentheses and braces?  Nested
expressions with lots of ()'s are a lot harder to decipher than a few
nested comments.  If your text editor already provides assistance with
finding matching () and {} then extending it to /* */ isn't that hard.

|> In my experience, among the subtlest and most difficult-to-find errors
|> involve missing comment terminators. I once worked on a program that had
|> been in use for years, yet I accidently noticed a missing comment terminator
|> that meant an intended line of code had never been compiled into the program.
|> It seems to me that nested comments make this situation worse, not better.
|> If you avoid "/*" comments in favor of "//" comments, you elminate the problem.

If this is a problem then use an editor that visually marks commented
areas.  The one I use here at work uses an italic font for comments and
it has been ages since I messed up a comment.

|> If you want to comment out several lines of code in C++, you have three
|> options:
|>
|> 1. Insert a "//" at the start of each line.

This is a pain to do and undo unless you write a "comment this area"
macro or something for your editor.

|> 2. Insert a "/*" at the start of each line and add "/**/" after the last line --
|>    but this won't work if a line contains an embedded comment. (I suppose that
|>    is your complaint.)

This is even more a pain than #1.

|> 3. Insert "#if 0" ahead of the first line and "#endif" after the last line.

This isn't really a comment since there are things you can put in a
"real" comment that you couldn't put in here (though you aren't too
likely to do so).  If mixed in with other #if/#endif's these are just
as difficult to decipher or even moreso than nested comments.

|> Options 1 and 3 are perfectly safe. Option 3 strikes me as equivalent to
|> using "/*" and "*/", and the #if/#endif pairs do nest.
|>
|> If you adopt a coding style whereby you only use "//" comments, you can comment
|> out any section of code with "/*" and "*/".

Unless you've already commented out a subsection of the code.  Or are
working with code that has to work for both C and C++ (like a common
header file).

The lack of nested comments isn't a problem.  At worst it is a very
minor deficiency with tolerable (though ugly) workarounds such as
those you outlined above.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ofm6g$4b4@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.sun.com> wrote:
>In my experience, among the subtlest and most difficult-to-find errors
>involve missing comment terminators. I once worked on a program that had
>been in use for years, yet I accidently noticed a missing comment terminator
>that meant an intended line of code had never been compiled into the program.
>It seems to me that nested comments make this situation worse, not better.

Graham Stoney wrote:
] I think this example runs counter to your argument; a compiler supporting
] nested comments would easily pick up such an error when it found that one of
] the comments was never terminated.

In article <31ADD801.6754@platsol.com>, Dave Toland  <det@platsol.com> wrote:
}And on what line would it flag the error?  On the last line of the source file.
}Not very useful.

That would be a quality of implementation issue; it certainly wouldn't be
difficult for the error message to reference the line the comment started on,
but either way at least the error would be flagged. Note that I'm not
advocating nested comments here; I'm just pointing out that Steve's example
appears to support nested over non-nested comments. Nested comments have pro's
and con's, but this is a pro rather than a con, if you like.

}On the other hand, a compiler that rejects nested comments could warn if it
}saw a start-comment-token while still within a comment.  That will certainly
}be MUCH closer to where the end-comment-token is missing.

As mentioned above, it's fairly trivial for a compiler supporting nested
comments to point out the start of the actual comment where the
end-comment-token is missing, rather than the next comment, which isn't
actually in error. Either way though, it's not a particularly strong argument
for or against nested comments, since a C/C++ compiler can always provide the
warning Dave mentions, as gcc's -Wcomment flag does for instance.

>3. Insert "#if 0" ahead of the first line and "#endif" after the last line.

] This solution has the disadvantage that the code between the "#if 0" and
] "#endif" must still consist of valid preprocessor tokens, so you can't use it
] to comment out arbitrary text.

}Exactly what kind of garbage are you trying to comment out???

I didn't say it was a particularly compelling disadvantage; I was just
pointing out that #if 0/#endif it isn't really equivalent to multi-line
commenting with /* */. You may have pseudo-like code that doesn't compile yet,
or anything you like. #if 0/#endif is certainly one solution I use, but once
again it's not without its pros and cons either. Nested comments would be a
more general solution here, although #ifdefs often work in practice.

Personally, I'm inclined to think that 'C' comments have never nested, and
that's the way it should stay. The reasons for changing it aren't sufficiently
compelling or unilateral. Ultimately, I doubt it makes a measurable difference.

Regards,
Graham


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Dave Toland (det@platsol.com) wrote:
| Graham Stoney wrote:
| > I think this example runs counter to your argument; a compiler supporting
| > nested comments would easily pick up such an error when it found that one of
| > the comments was never terminated.
|
| And on what line would it flag the error?  On the last line of the source
| file.  Not very useful.

Not necessarily.  It could flag the error at the *start* of the comment.

Anyway, what's the difference between that and the following ?

 #if 1
 #if 2
 #endif
 //
 // 1 million lines of C++ source
 //
 // End-Of-File

Flagging the missing #endif 1 million lines too late is hardly useful, yet
I don't see anyone objecting to that.

Personally, most of the problems that people raise against the idea of
nested comments are easily solved with the use of a decent text editor.  Most
people seem averse to the idea of syntax-colouring text editors, or editors
with brace and comment matching, yet these same people seem happy to say
"oh, such-and-such problem can be easily diagnosed with lint".

It just seems terribly inconsistent.  If you are prepared to accept one
common external tool, you should be prepared to accept another.

Not that I'm advocating nested comments, BTW, even though I use a
syntax-colouring text editor myself (BOXER for OS/2).


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ok5qo$192a@news.rchland.ibm.com> seurer@rchland.ibm.com
(Bill Seurer) writes:



|> |> If you want to comment out several lines of code in C++, you have three
|> |> options:
|> |>
|> |> 1. Insert a "//" at the start of each line.

|> This is a pain to do and undo unless you write a "comment this area"
|> macro or something for your editor.

It's not really that difficult.  IMHO, this is the preferred solution,
since you can see at a glance what is comment and what isn't.  (Even
with C, I never used multi-line comments, preferring to close the
comment on every line, and reopen it on the next.  And yes, I set up
function keys to help do this in my editor.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <KANZE.96Jun1093622@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes:
|> In article <4ok5qo$192a@news.rchland.ibm.com> seurer@rchland.ibm.com
|> (Bill Seurer) writes:
|> |> |> If you want to comment out several lines of code in C++, you have three
|> |> |> options:
|> |> |>
|> |> |> 1. Insert a "//" at the start of each line.
|>
|> |> This is a pain to do and undo unless you write a "comment this area"
|> |> macro or something for your editor.
|>
|> It's not really that difficult.  IMHO, this is the preferred solution,
|> since you can see at a glance what is comment and what isn't.  (Even
|> with C, I never used multi-line comments, preferring to close the
|> comment on every line, and reopen it on the next.  And yes, I set up
|> function keys to help do this in my editor.)

But I can see what is and isn't a comment at a glance since I set up my
editor to show comments in italics.  Well, *I* didn't do it.  Some nice
guys who work on the editor did.  It also matches parentheses and braces
and does automatic indention if I ask and lots of other Good Stuff.  Using
an editor tuned to your language can prevent a lot of problems before you
even run the compiler.

If working with a plain text editor, though, I agree with you.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]