Talk:Comments

Pascal Comments

The Pascal section claims that '{' and '}' are Turbo Pascal extensions. However the Pascal Standard, ISO/IEC 7185:1990 explicitly contains:

6.1.8 Token separators

Where a commentary shall be any sequence of characters and separations of lines, containing neither

} nor *), the construct

( `{' | `(*' ) commentary ( `*)' | `}' )

shall be a comment if neither the { nor the (* occurs within a character-string or within a commentary.

NOTES

1 A comment may thus commence with { and end with *), or commence with (* and end with }.

2 The sequence (*) cannot occur in a commentary even though the sequence {) can.

Therefore { and } are comment delimiters in standard pascal. Note that comments like

(* this }

or

{ this *)

are valid Standard Pascal comments, but not valid Turbo Pascal comments.

Another interesting quote from the standard:

6.1.9 Lexical Alternatives

[...]

The comment-delimiting characters { and } shall be the reference representations, and (* and *)

respectively shall be alternative representations (see 6 .1 .8).

I guess it couldn't be more explicit :-) --Ce

Thanks for the clarification! I guess my memory was faulty. Personally, I always used { } in Turbo Pascal. --IanOsgood 18:33, 29 September 2007 (MDT)

C: #if 0 and syntax errors

The assertion was made that

#if 0
This isn't valid.	 
#endif	

would cause a compile error due to an unmatched apostrophe in a character literal. This is false. The preprocessor removes this text from the source before the compiler has a chance to parse it. --IanOsgood 18:59, 29 September 2007 (MDT)

Did you actually read the text you removed? The Compiler does not see the unterminated character constant, but the Preprocessor does. See e.g. http://c-faq.com/ansi/ifdefsyntax.html

Unfortunately I don't have the C standard, so I cannot quote directly from there, but I double-checked with C++ that both CD2 (latest public draft of the 1998 version) and n2009 (a draft for the next section) contain wording identically in both (i.e. with exrtemely high probability also in the real standard) that this is true in C++ as well. More exactly, character literals are preprocessing tokens, and translation to preprocessing tokens happens in translation phase 3, while processing of preprocessing directives (this includes #ifdef) doesn't happen until translation phase 4. --Ce 05:17, 30 September 2007 (MDT)

Egads! The reason I disbelieved you is that I have never used a C compiler which actually obeyed this part of the standard. The snippet compiles fine in gcc 3.4 and 4.0.1. I even tried with -std=c99 -pedantic-errors options for all supported standards. I also tried with just the preprocessor cpp in isolation.

I believe this section should be prefaced with "Standard: ANSI, but not GCC" or a list of compilers which exhibit this behavior. Which C/C++ compiler are you using which fails on the above snippet? --IanOsgood 09:57, 30 September 2007 (MDT)

BTW, thanks for the detailed references, Ce! Perhaps Rosetta Code should be more like Wikipedia and encourage references on the pages themselves. It might avoid this kind of argument in the future. --IanOsgood 10:58, 30 September 2007 (MDT)

Any reference should be linked. As long as it's relevant to the project, language or code used. Even though we provide a lot of code in Rosetta Code, sometimes this isn't enough. I don't see why we shouldn't allow anyone to read more on a given subject. This is of course true for this issue, but it also is for any other. --CrashandDie 01:11, 5 October 2007 (MDT)

Python: move docstrings to its own task

Python docstrings are not comments and are not ignored by the compiler/interpreter. Strings in the source are also not ignored - they are probably crated and destroyed at runtime, and are not the way to comment code.

We can add the Pythonic way to comment code:

if 0:
    print 'this line is commented out'
    print 'so is this line'