Since nested comments aren't allowed, and the preprocessor's gone, how am I going to comment out large chunks of code without worrying about comments in the middle?

My usual procedure was to say:

#if 0
  code, comments, and other preprocessor statements.
#endif

Doing the next best thing isn't that good:
/*
   code, preprocessor statements, but no comments
*/

Note, this is my debugging style.  I also use unlink("----------part 1") for easy, unbuffered and strace-able debugging messages.  Having printf buffer my debug messages makes it look like the error is somewhere other than where it is.

"croot" <nfudd@mellor.bc.ca> wrote in message news:3B7C0381.445EF50@mellor.bc.ca...
> Since nested comments aren't allowed, and the preprocessor's gone, how am I going to comment out large chunks of code without worrying about comments in the middle?
>
> My usual procedure was to say:
>
> #if 0
>   code, comments, and other preprocessor statements.
> #endif
>
> Doing the next best thing isn't that good:
> /*
>    code, preprocessor statements, but no comments
> */

That's a great question. In D, semantic processing occurs outside in, so you can remove blocks of code with:

    if (0)
    {
            blah, blah
    }

The code between the { } would have to be syntactically correct, but not semantically correct. This is unlike C, where it'd have to be semantically correct (i.e. no undefined variables, etc.).


> Note, this is my debugging style.  I also use unlink("----------part 1") for easy, unbuffered and strace-able debugging messages.  Having printf buffer my debug messages makes it look like the error is somewhere other than where it is.

I use printf() for inserting debug messages. I don't know why writing your own debug printing routine wouldn't work, also, you can prefix them with the debug attribute and have then turned on and off by a compiler switch.

Actually, I'd like to comment on comments in general:

with C99 (and with gcc for quite a while now)

the // comment is legal.

However, what happens when you do

          // big long comment here \
          int i = 7;


          ...
          i++;

is that you get an error from the compiler telling you
that i hasn't been declared.

In my opinion, this is ridiculous, because you might
well want to comment out some code that has a \ on the
line and you wouldn't necessarily catch it.

What approach are you taking for this?

Walter wrote:

> I use printf() for inserting debug messages. I don't know why writing your own debug printing routine wouldn't work, also, you can prefix them with the debug attribute and have then turned on and off by a compiler switch.

No, the issue is that by default printf() buffers its output.  This means that you need to call fflush(stdout) after every debug call, otherwise the error message may get printed later on or possibly not at all if the program hangs before the buffer gets flushed.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

No backslash line splicing is the approach D takes. The \ in C is for two reasons:

1) multiline macros
2) for some reason, some devices can't handle long lines, so the \ was put
in so long lines could be arbitrarilly wrapped to the next line.

I don't see a need to support either (1) or (2).

"Matt Gessner" <mattg@aiinet.com> wrote in message news:3B7C182A.8010209@aiinet.com...
> Actually, I'd like to comment on comments in general:
>
> with C99 (and with gcc for quite a while now)
>
> the // comment is legal.
>
> However, what happens when you do
>
>            // big long comment here \
>            int i = 7;
>
>
>            ...
>            i++;
>
> is that you get an error from the compiler telling you
> that i hasn't been declared.
>
> In my opinion, this is ridiculous, because you might
> well want to comment out some code that has a \ on the
> line and you wouldn't necessarily catch it.
>
> What approach are you taking for this?
>

Matt Gessner wrote:
> However, what happens when you do
> 
>            // big long comment here \
>            int i = 7;
> 
>            ...
>            i++;
> 
> is that you get an error from the compiler telling you
> that i hasn't been declared.
> 
> In my opinion, this is ridiculous, because you might
> well want to comment out some code that has a \ on the
> line and you wouldn't necessarily catch it.
> 
> What approach are you taking for this?

According to the doc, there's no line-continuation backslash in D.

-Russell B

croot wrote:
> 
> Since nested comments aren't allowed, and the preprocessor's gone, how am I going to comment out large chunks of code without worrying about comments in the middle?
> 
> My usual procedure was to say:
> 
> #if 0
>   code, comments, and other preprocessor statements.
> #endif
> 
> Doing the next best thing isn't that good:
> /*
>    code, preprocessor statements, but no comments
> */

I always use // comments to remove large blocks of code. I prefer it over the "#if 0/#endif" technique because if the start of the commented-out portion scrolls off the top of the screen, it's still clear that the code is inactive (particularly if the editor colors commented code distinctively); it also is compatible with both /* */ and // comments in the commented-out section.

-Russell B

Russell Bornschlegel wrote:
> 
> croot wrote:
> 
>>Since nested comments aren't allowed, and the preprocessor's gone, how
>>am I going to comment out large chunks of code without worrying about
>>comments in the middle?
>>
>>My usual procedure was to say:
>>
>>#if 0
>>  code, comments, and other preprocessor statements.
>>#endif
>>
>>Doing the next best thing isn't that good:
>>/*
>>   code, preprocessor statements, but no comments
>>*/
>>
> 
> I always use // comments to remove large blocks of code. I prefer it over the "#if 0/#endif" technique because if the start of the commented-out portion scrolls off the top of the screen, it's still clear that the code is inactive (particularly if the editor colors commented code distinctively); it also is compatible with both /* */
> and // comments in the commented-out section. 
> 
> -Russell B
> 

Vim (and presumably emacs, but I don't use it) will syntax color "#if 0" code the same  color as your comments.  So, it's exactly (color wise) as if you put those "//" at the front of every line.  Also, it will jump to the matching "#if" statement, so you can easily find the other end of the block.  This makes "#if 0" much easier, in my opinion, than "//". However, it could be taught to tread "if (0)" the same as it treats "#if    0" now, so that's not really an issue.

Daniel

As long as you don't compile with that version it shouldn't be compiled in, although it is still syntacticlly checked I believe.

version( 4996588482.1 ) {
  ...
  ...
}

-Chris

Daniel Gryniewicz wrote:

> Russell Bornschlegel wrote:
>> 
>> croot wrote:
>> 
>>>Since nested comments aren't allowed, and the preprocessor's gone, how am I going to comment out large chunks of code without worrying about comments in the middle?
>>>
>>>My usual procedure was to say:
>>>
>>>#if 0
>>>  code, comments, and other preprocessor statements.
>>>#endif
>>>
>>>Doing the next best thing isn't that good:
>>>/*
>>>   code, preprocessor statements, but no comments
>>>*/
>>>
>> 
>> I always use // comments to remove large blocks of code. I prefer it over the "#if 0/#endif" technique because if the start of the commented-out portion scrolls off the top of the screen, it's still clear that the code is inactive (particularly if the editor colors commented code distinctively); it also is compatible with both /* */ and // comments in the commented-out section.
>> 
>> -Russell B
>> 
> 
> Vim (and presumably emacs, but I don't use it) will syntax color "#if 0"
> code the same  color as your comments.  So, it's exactly (color wise) as
> if you put those "//" at the front of every line.  Also, it will jump to
> the matching "#if" statement, so you can easily find the other end of
> the block.  This makes "#if 0" much easier, in my opinion, than "//".
> However, it could be taught to tread "if (0)" the same as it treats "#if
>     0" now, so that's not really an issue.
> 
> Daniel
> 
> 

In article <9oe3pe$30ii$3@digitaldaemon.com>,
 Chris Holland <cholland@whitecapdirect.com> writes:
|> As long as you don't compile with that version it shouldn't be compiled in,
|> although it is still syntacticlly checked I believe.
|>
|> version( 4996588482.1 ) {
|>   ...
|>   ...
|> }
|>
|> -Chris
|>
|> Daniel Gryniewicz wrote:
|>
|> > Russell Bornschlegel wrote:
|> >>
|> >> croot wrote:
|> >>
|> >>>Since nested comments aren't allowed, and the preprocessor's gone, how
|> >>>am I going to comment out large chunks of code without worrying about
|> >>>comments in the middle?
|> >>>
|> >>>My usual procedure was to say:
|> >>>
|> >>>#if 0
|> >>>  code, comments, and other preprocessor statements.
|> >>>#endif
|> >>>
|> >>>Doing the next best thing isn't that good:
|> >>>/*
|> >>>   code, preprocessor statements, but no comments
|> >>>*/

In D there already is such a possibility, using HTML as source:

<code> // start of code

    Blah blah ...  some code
    ...

</code> // start of "commented out" code
    blah blah ...
    ...
<code> // end of "commented out" code
    blah blah ...
    ....

I also thnik it's an useful feature to comment out big parts of
a program, but in my opinion all methods exposed are a little
tricky. There should be a specific way to accomplish this task.

Some specific characters can be used to achieve this, i.e.:

@@@
  This is a comment that spans on more lines.
  All characters after the first @@@ at column 0 are ignored
  until the end of line after the second @@@ at column 0
@@@

Being line-based comments, they must start at column 0 to be considered. The two lines with the strting @@@ can be considered in two ways:

1 - they are commented lines, so any trailing character is ignored
2 - they must be the only thing in the line, so any trailing
    character is a lexical error.

I prefer option 2, but I don't exclude option 1.

Being invalid characters they can be treated directly by the lexical scanner, without much effort.

Ciao