Why don't C comments nest?

Discussion in 'C Programming' started by Al, Jul 13, 2007.

  1. Al

    Al Guest

    Hi all,

    (Apologies if this is in a FAQ somewhere, I couldn't find anything).

    Almost every time I do any significant amount of coding in C or C++, I
    end up wishing C-style comments would nest. It would make rapid
    debugging much more convenient (vs. #if 0/#endif or editor macros).

    Anyway, was this an explicit design decision, or some sort of historical
    artifact? (e.g. too expensive to parse at the time). What other sorts of
    reasons might exist against nesting comments?

    Thanks!
    -Al-
    Al, Jul 13, 2007
    #1
    1. Advertising

  2. Al said:

    > Hi all,
    >
    > (Apologies if this is in a FAQ somewhere, I couldn't find anything).
    >
    > Almost every time I do any significant amount of coding in C or C++, I
    > end up wishing C-style comments would nest. It would make rapid
    > debugging much more convenient (vs. #if 0/#endif or editor macros).


    Personally, I find #if 0/#endif quicker and more intuitive. I prefer to
    reserve comment syntax for actual comments on the code that there is,
    rather than use it to create ghosts of the code that there isn't.

    > Anyway, was this an explicit design decision, or some sort of
    > historical artifact? (e.g. too expensive to parse at the time). What
    > other sorts of reasons might exist against nesting comments?


    Neither the C Standard nor K&R2 have anything to say about the reasoning
    behind this decision. The C Rationale, however, suggests that the ISO C
    Committee managed to predict ahead of time that I wouldn't like the
    idea of nested comments, and arranged matters such that I would not be
    disappointed. It says:

    The Committee considered proposals to allow comments to nest. The main
    argument for nesting comments is that it would allow programmers to
    ``comment out'' code. The Committee rejected this proposal on the
    grounds that comments should be used for adding documentation to a
    program, and that preferable mechanisms already exist for source code
    exclusion. For example,

    #if 0
    /* this code is bracketed out because ... */
    code_to_be_excluded();
    #endif

    Preprocessing directives such as this prevent the enclosed code from
    being scanned by later translation phases. Bracketed material can
    include comments and other, nested, regions of bracketed code.

    Another way of accomplishing these goals is with an if statement:

    if (0) {
    /* this code is bracketed out because ... */
    code_to_be_excluded();
    }

    Many modern compilers will generate no code for this if statement.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jul 13, 2007
    #2
    1. Advertising

  3. Al

    Eric Sosman Guest

    Al wrote:
    > Hi all,
    >
    > (Apologies if this is in a FAQ somewhere, I couldn't find anything).


    This is Question 20.20 in the comp.lang.c Frequently
    Asked Questions (FAQ) list at <http://c-faq.com/>. It is
    hard to imagine how you could have missed it, since the
    text of the question contains an *exact* replica of your
    Subject line.

    --
    Eric Sosman
    lid
    Eric Sosman, Jul 13, 2007
    #3
  4. "Al" <> wrote in message
    news:...
    >
    > Anyway, was this an explicit design decision, or some sort of historical
    > artifact? (e.g. too expensive to parse at the time). What other sorts of
    > reasons might exist against nesting comments?


    Generally, the probability of a human making a mistake in interacting with a
    certain type of system is correlated with how much state the system holds.

    In terms of the probability that a person will make a mistake when using
    nested comments, note that:

    a)Without nested comments, the parser state is known after "*/". With
    nested comments, it is not.

    b)Nested comments provide more possibilites for a person to accidentally
    comment out portions of code without realizing it (leading to severe bugs).

    Of course, one could make the same argument with #if 0, but it seems to me
    that the human eye just isn't very good at picking out "/*" and "*/" and
    matching them up in a complex stream of characters.

    I don't disagree with the decision to not support nested comments. It is
    just one more path for accidents.

    --
    David T. Ashley ()
    http://www.e3ft.com (Consulting Home Page)
    http://www.dtashley.com (Personal Home Page)
    http://gpl.e3ft.com (GPL Publications and Projects)
    David T. Ashley, Jul 13, 2007
    #4
  5. Al

    Al Guest

    Eric Sosman wrote:
    <snip>
    > This is Question 20.20 in the comp.lang.c Frequently
    > Asked Questions (FAQ) list at <http://c-faq.com/>. It is
    > hard to imagine how you could have missed it, since the
    > text of the question contains an *exact* replica of your
    > Subject line.


    Ah, good catch, sorry about that. I was looking for a section about
    Comments and didn't realize it was in Miscellaneous instead. So, I guess
    it goes back further than C to PL/I and beyond.


    Thanks,
    -Al-
    Al, Jul 13, 2007
    #5
  6. Al

    Army1987 Guest

    On Fri, 13 Jul 2007 00:33:08 -0700, Al wrote:

    > Hi all,
    >
    > (Apologies if this is in a FAQ somewhere, I couldn't find anything).
    >
    > Almost every time I do any significant amount of coding in C or C++, I
    > end up wishing C-style comments would nest. It would make rapid
    > debugging much more convenient (vs. #if 0/#endif or editor macros).
    >
    > Anyway, was this an explicit design decision, or some sort of historical
    > artifact? (e.g. too expensive to parse at the time).

    I don't think that's the reason. I've never written a
    preprocessor, but I think that to enable nested comments one would
    just need a counting variable incremented for each /* and
    decremented for each */, instead of a Boolean variable set and
    reset. You might add a translation limit of "32767 nested
    comments".

    But they wouldn't be that useful. I agree with DTA.
    --
    Army1987 (Replace "NOSPAM" with "email")
    "Never attribute to malice that which can be adequately explained
    by stupidity." -- R. J. Hanlon (?)
    Army1987, Jul 14, 2007
    #6
  7. Army1987 wrote:
    > On Fri, 13 Jul 2007 00:33:08 -0700, Al wrote:
    >
    >> Hi all,
    >>
    >> (Apologies if this is in a FAQ somewhere, I couldn't find anything).
    >>
    >> Almost every time I do any significant amount of coding in C or C++, I
    >> end up wishing C-style comments would nest. It would make rapid
    >> debugging much more convenient (vs. #if 0/#endif or editor macros).
    >>
    >> Anyway, was this an explicit design decision, or some sort of historical
    >> artifact? (e.g. too expensive to parse at the time).

    > I don't think that's the reason. I've never written a
    > preprocessor, but I think that to enable nested comments one would
    > just need a counting variable incremented for each /* and
    > decremented for each */, instead of a Boolean variable set and
    > reset. You might add a translation limit of "32767 nested
    > comments".


    As simple as that is, it could be even simpler: preprocessors may have a
    function designed specifically to skip comments. This function may already
    check for /* to give a warning that C comments do not nest. (Both are true
    in some preprocessors, but I of course cannot speak about all.) All it
    would need to do is call itself recursively instead of giving this warning.
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 14, 2007
    #7
  8. On Fri, 13 Jul 2007 08:07:42 +0000, Richard Heathfield wrote:
    >Personally, I find #if 0/#endif quicker and more intuitive. I prefer to
    >reserve comment syntax for actual comments on the code that there is,
    >rather than use it to create ghosts of the code that there isn't.


    But aren't the #if 0/#endif the 'ghosts' in the code? Comments are
    visibly distinguished by most modern syntax-highlightning editors, #if
    0/#endif sections not (unless you use the new Eclipse CDT 4.0 with
    'Inactive Code Highlighting' http://preview.tinyurl.com/2jwaed).

    >Another way of accomplishing these goals is with an if statement:
    >
    >if (0) {
    > /* this code is bracketed out because ... */
    > code_to_be_excluded();
    > }
    >
    >Many modern compilers will generate no code for this if statement.


    Modern compilers should create a warning for this code.

    IMO, the best way to comment out lange sections of code are //
    comments for which hotkeys are provided by many IDEs and editors.


    --
    Roland Pibinger
    "The best software is simple, elegant, and full of drama" - Grady Booch
    Roland Pibinger, Jul 14, 2007
    #8
  9. Al

    Chris Dollin Guest

    Roland Pibinger wrote:

    > On Fri, 13 Jul 2007 08:07:42 +0000, Richard Heathfield wrote:


    >>Another way of accomplishing these goals is with an if statement:
    >>
    >>if (0) {
    >> /* this code is bracketed out because ... */
    >> code_to_be_excluded();
    >> }
    >>
    >>Many modern compilers will generate no code for this if statement.

    >
    > Modern compilers should create a warning for this code.


    So long as I can tell them DON'T DO THAT, that's OK.

    > IMO, the best way to comment out lange sections of code are //
    > comments for which hotkeys are provided by many IDEs and editors.


    I agree that's an excellent suggestion, but it only works for
    languages with // (or similar end-of-line) comments.

    --
    Such As C++ And C90 But Not C89 Hedgehog
    "It took a very long time, much longer than the most generous estimates."
    - James White, /Sector General/
    Chris Dollin, Jul 14, 2007
    #9
  10. Roland Pibinger said:

    > On Fri, 13 Jul 2007 08:07:42 +0000, Richard Heathfield wrote:
    >>Personally, I find #if 0/#endif quicker and more intuitive. I prefer
    >>to reserve comment syntax for actual comments on the code that there
    >>is, rather than use it to create ghosts of the code that there isn't.

    >
    > But aren't the #if 0/#endif the 'ghosts' in the code? Comments are
    > visibly distinguished by most modern syntax-highlightning editors, #if
    > 0/#endif sections not (unless you use the new Eclipse CDT 4.0 with
    > 'Inactive Code Highlighting' http://preview.tinyurl.com/2jwaed).


    My six-year-old copy of vim seems to manage it:

    <http://www.cpax.org.uk/scratch/vimcolour.png>

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Jul 14, 2007
    #10
  11. Chris Dollin wrote:
    > Roland Pibinger wrote:
    >> IMO, the best way to comment out lange sections of code are //
    >> comments for which hotkeys are provided by many IDEs and editors.

    >
    > I agree that's an excellent suggestion, but it only works for
    > languages with // (or similar end-of-line) comments.
    >
    > --
    > Such As C++ And C90 But Not C89 Hedgehog
    > "It took a very long time, much longer than the most generous estimates."
    > - James White, /Sector General/


    I think you mean "Such As C++ And C99 But Not C90/C89".
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 14, 2007
    #11
  12. Al

    Chris Dollin Guest

    Harald van Dijk wrote:

    > Chris Dollin wrote:
    >> Roland Pibinger wrote:
    >>> IMO, the best way to comment out lange sections of code are //
    >>> comments for which hotkeys are provided by many IDEs and editors.

    >>
    >> I agree that's an excellent suggestion, but it only works for
    >> languages with // (or similar end-of-line) comments.
    >>
    >> --
    >> Such As C++ And C90 But Not C89 Hedgehog
    >> "It took a very long time, much longer than the most generous estimates."
    >> - James White, /Sector General/

    >
    > I think you mean "Such As C++ And C99 But Not C90/C89".


    I think I /should/ have meant, and said, that. Ta.

    --
    Far-Fetched Hedgehog
    "Never ask that question!" Ambassador Kosh, /Babylon 5/
    Chris Dollin, Jul 14, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    1,095
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    862
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,761
    Smokey Grindel
    Dec 2, 2006
  4. Monk
    Replies:
    10
    Views:
    1,438
    Michael Wojcik
    Apr 20, 2005
  5. Aron Packer

    Why don't C comments nest?

    Aron Packer, Nov 11, 2011, in forum: C Programming
    Replies:
    75
    Views:
    1,715
    Phil Carmody
    Nov 18, 2011
Loading...

Share This Page