Commenting out a comment

[ab1jx]

I just discovered that this works, never tried it before. If you've got

Code: Select all

/*
  some section you want to disable here
*/

You can add // to change the /* and */ to ///* and //*/ to re-enable the commented out section but leave it marked so it's like.

Code: Select all

///*
  some section you want to disable here (this is now active)
//*/

Then later you can delete the commenting lines to make the section permanent or delete the // to comment it back out. Works in this GCC 6.3 anyway.

[Paeryn]

That's because after starting a comment with // all the characters up to the newline (but not including it) are effectively ignored. The only processing the compiler does on those characters in-between is to determine when the end of the line is reached, it never sees the start of another comment if it is already is processing one. It's the same reason as to why you can't nest the traditional comments /* ... */

Code: Select all

/*
/* This won't compile */
*/

[ab1jx]

Right, I've gotten the "multiline comment" warning if I have a line continued with a \ at the end then use // at the beginning of both. Commenting only the first line doesn't work, I guess because the \ is ignored after the // is there.

I've used

Code: Select all

/*
// old comment
old code
*/

before, I just never had a reason to do the opposite before. Very glad to find it worked.

[ejolson]

Right, I've gotten the "multiline comment" warning if I have a line continued with a \ at the end then use // at the beginning of both. Commenting only the first line doesn't work, I guess because the \ is ignored after the // is there.

I've used

Code: Select all

/*
// old comment
old code
*/

before, I just never had a reason to do the opposite before. Very glad to find it worked.

I think the standard way is something like

Code: Select all

#if 0

code that is commented out

#endif

This works because preprocessor defines nest properly as opposed to comment delimiters.

[Paeryn]

gcc will warn you (when asked to) if it sees either a /* inside a /* */ comment or if a // comment ends a line with a backslash as both of these are likely to be programmer errors. Backslash-newline isn't a newline, it is stepped over as if it were not there effectively joining the two lines as one, so if you use // comment \ then the line following will also be considered to be part of the comment.

Code: Select all

#include <stdio.h>

int main(void)
{
    int fr\
ed = 0;
    /** The above will be treated as is if you wrote
    int fred = 0;
    **/
//  printf("Hello\n"); \
    printf("World\n");
    return 0;
}

will compile but running it will produce no output as the second printf line is considered to be part of the previous line and so both are commented out.

[jahboater]

I think the standard way is something like

Code: Select all

#if 0

code that is commented out

#endif

This works because preprocessor defines nest properly as opposed to comment delimiters.

+1 yes indeed.
As for comments, the C17 standard says ...

Code: Select all

6.4.9 Comments

1 Except within a character constant, a string literal, or a comment, the characters /*
introduce a comment. The contents of such a comment are examined only to identify
multibyte characters and to find the characters */ that terminate it. 83)

2 Except within a character constant, a string literal, or a comment, the characters //
introduce a comment that includes all multibyte characters up to, but not including, the
next new-line character. The contents of such a comment are examined only to identify
multibyte characters and to find the terminating new-line character.

[ab1jx]

I think the standard way is something like

Code: Select all

#if 0

code that is commented out

#endif

This works because preprocessor defines nest properly as opposed to comment delimiters.

This is nice because (maybe) you can have // and /* */ comments inside. /* */ comments are a nuisance because you can't nest them, but they're faster than adding // to each line. It seems to be mostly a problem if you imported something written in a different program, or by somebody else.

But ///* is something else again because it uncomments what was originally commented. I suppose in the define you'd just change "if 0" to "if 1".

[jahboater]

But ///* is something else again because it uncomments what was originally commented. I suppose in the define you'd just change "if 0" to "if 1".

Yes exactly.
And you don't have to alter the commented out code in any way - the lines remain untouched.
Furthermore, you can provide alternative code ...

Code: Select all

#if 0

old code

#else

new code to try ...

#endif

again without messing with the commented out code.

[ab1jx]

I was poking around in X header files (the source of most knowledge) and wanted to quote this section in my program code until I get it working. Compiles fine.

Code: Select all

#if (0)
extern void XSetWMName(
    Display*            /* display */,
    Window              /* w */,
    XTextProperty*      /* text_prop */
);

which calls:

extern void XSetTextProperty(
    Display*            /* display */,
    Window              /* w */,
    XTextProperty*      /* text_prop */,
    Atom                /* property */
);

And bear this in mind:

/*
 * new structure for manipulating TEXT properties; used with WM_NAME,
 * WM_ICON_NAME, WM_CLIENT_MACHINE, and WM_COMMAND.
 */
typedef struct {
    unsigned char *value;               /* same as Property routines */
    Atom encoding;                      /* prop type */
    int format;                         /* prop data format: 8, 16, or 32 */
    unsigned long nitems;               /* number of data items in value */
} XTextProperty;

#endif

Using #if (0) let me leave the whole thing intact and just copy and paste it in. With the original comments.

[Heater]

Yuk,

I do wish /* something I want */
people /* The X authors in this case */
would not intermingle comments /* confuse */
with their code like that. /* example above */

And what nonsense is that anyway? A prime example of meaningless, useless comments that clutter up the place and confuse things making the code harder to read.

For exampe the parameter is called "Display" in the code and the comment beside it is "display". Why do that? Same for "Window" and "XTextProperty".

[stefanv]

I agree that the comments in the example above are pointless, but having them intermingled with code can be very helpful (just like parenthetical remarks in English prose) to understanding the code.

[Heater]

Yes indeed. Comments are there to aid understanding of the code.

Problem is that, like all writing, it has to be targeted at some audience or other.

Code examples that one might expect beginners to read might need detailed comments.

Those same comments in the same code will be really annoying to a team of experienced engineers.

Then as the years go by code gets changed but people forget to change the comments accordingly. The comments end up being misleading and wrong. Which can waste a lot of time for anyone new to the project.

I have worked on projects where it was mandated that almost every line of code was commented. The result of that was a lot of noise like:

/* Increment a */
a += 1;

After some decades of dealing with code I'm still not sure of the best way to comment it.