www.digitalmars.com         C & C++   DMDScript  

D - Commenting out code

reply croot <nfudd mellor.bc.ca> writes:
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.
Aug 16 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Aug 16 2001
next sibling parent reply Matt Gessner <mattg aiinet.com> writes:
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?
Aug 16 2001
next sibling parent "Walter" <walter digitalmars.com> writes:
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?
Aug 16 2001
prev sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 16 2001
prev sibling parent Chris Friesen <cfriesen nortelnetworks.com> writes:
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
Aug 16 2001
prev sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 16 2001
parent reply Daniel Gryniewicz <johndoe fprintf.net> writes:
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
Aug 28 2001
parent reply 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
*/


 
 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
Sep 20 2001
parent mario jonathan.torino.artis.it (Roberto Mariottini) writes:
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
Sep 21 2001