tags:

views:

276

answers:

8

I was discussing C programming styles with some students and when we were talking about comments, one of them noted that he doesn't use C++ comments in C code because they are a bad idea. Turns out that it was based on personal experience with multi-line C++ comments, but it's not the first time I've heard that claim. So, is // considered harmful and if so, then why?

+6  A: 

If you use C++ comments in C, chances are that some C compilers won't accept your code. I would consider this harmful.

norheim.se
+1 for an obviously correct answer.
Will A
Good point. I haven't seen such a compiler in the last 20 years, but that would be the only reason where it is harmful. Otoh stripping out C++ comments from a project takes an hour max.
Nils Pipenbrinck
An hour? Max 5 minutes to write a Perl script...
Kornel Kisielewicz
@Nils: Embedded C compilers generally follow C90, even today. C99 added too much cruft that they didn't want.
Philip Potter
In an embedded project, where older software is found more often, this in fact happens. And why strip out comments that should have been formatted correctly in the first place?
MaxVT
@Kornel A Perl scripts that works with string literals, digraphs and trigraphs? In 5 minutes? Could you make it fit in a SO comment too, I am curious...
Pascal Cuoq
@Phillip, I do embedded development as a job. Most of them don't support C99, but even the oldest once, from the pre-C90 days allow C++ comments as an extension.
Nils Pipenbrinck
@Pascal: trigraphs? who uses them?
Philip Potter
@Pascal, if you're using digraphs and trigraphs, C++ style comments are not your biggest problem :P
Kornel Kisielewicz
A: 

Saying something is a bad idea without any kind of justification seems like a bad idea to me.

The only problem I can see // causing is when you're using older compilers that don't support that kind of comment.

Martinho Fernandes
You will have to justify why that seems a bad idea to you. `:)`
sbi
+13  A: 

It depends what version of C you are using. C 99 allows // as a comment, whereas C 89 doesn't.

If you want to be as backward compatible as possible, don't use them. But, I think this is an extreme fringe case. I'm willing to bet almost everyone uses C 99.

Edit: Any recent version of GCC is uses most of C99. You can find more info in Wikipedia.

Codeacula
my standard gcc options are `-ansi -pedantic -W -Wall` which makes gcc very strict at rejecting and warning about bad code. It also rejects `//` comments. You can use `-std=c99` rather than `-ansi` if you want to accept C99 stuff but maintain the strictness, but I prefer my C code to be as widely compatible as possible.
Philip Potter
I honestly am not that experienced in compiler options. I'm still learning to use pointers correctly ;). I was a PHP guy getting into C/C++ on my own. I just know the difference because I had the same question myself back when I was in highschool.
Codeacula
+2  A: 

C++-style comments were added to C with the (not yet widely supported) C99 standard. While the standard itself isn't widely supported in full, some parts of it (like the C++ style comments), are supported in almost every compiler by now. Considering that they were added, it means that there's a need for them, so it's easy to figure out that it wouldn't be considered bad style -- especially if you set yourself guidelines on where to use which.

Only reason not to use them is if you want to write a well-formed C89 compilant program.

Kornel Kisielewicz
C99 is not widely supported? Which current available C compilers does not support C99? I mean, at least most of C99 including //-Comments ...
maxschlepzig
@maxschlepzig, which compiler **does** support C99?
Kornel Kisielewicz
@maxschlepzig: That's easy - MSVC.
kusma
@kusma, and GCC, Intel C, Clang, and actually any compiler except Sun Studio...
Kornel Kisielewicz
@Kornel: He did say "...at least most of C99 including //-Comments". I believe all the ones you mentioned does support a relatively large subset of C99, including C++-style comments.
kusma
@kusma, for me, supporting C99 means at least supporting VLA's and the 'restrict' keyword fully, you'll agree that compared to that C++-style comments are just nonimportant sugar.
Kornel Kisielewicz
@Kornel, 'restrict' and VLAs are neat, but I think stuff like stdint.h, long long int support and most importantly designated initializers are much more vital. VLAs can easily be emulated with alloca(), and 'restrict' is just a hint for the optimizer.
kusma
@kusma, stdint.h can be written yourself, I'll agreee on long long and initializers though.
Kornel Kisielewicz
@Kornel: gcc does at support most of C99, including VLAs and `restrict` - the [remaining issues](http://gcc.gnu.org/c99status.html) seem to mostly be around the new floating point semantics and math functions.
caf
A: 

"//" is supported in C99, but in C89 (which is the by far most supported dialect) it's not supported.

kusma
+1  A: 

One common reason why people use // instead of /* */ is that you can "nest" the former and not the latter, and so you can comment out code that has comments in it. But you should really be using #if 0 for commenting out code in C anyways.

Radomir Dopieralski
Actually, you should use a version control system to keep track of old, unused code ;)
kusma
Unless you are testing a change that is not supposed to get commited.
Radomir Dopieralski
No, you should still use the version control system. The VCS should already have a copy of the code, so you can safely delete it. Then it's a simple matter of resurrecting it from the VCS later.
kusma
Sometimes it's the new code that you are writing that you want to disable. But I agree that no commented-out code should go into the repository, unless they are examples or something like python's doctests.
Radomir Dopieralski
Well, I'm a Git user so I just stuff all code I write into my local repo as I hack. Then I clean up afterwards before I share it. Having the history as you hacked some feature is really useful, much more so than manual book-keeping with "#if 0"-nastiness ;)
kusma
If you have changes which "aren't supposed to get committed" then you are asking your VCS to do too many separate jobs. Is it there to keep a complete history of the code, or is it there to help share code between different users? What happens when you are hacking and want to store changes but you don't want to share them yet? Distributed VCSes solve this problem by separating these concerns of recording history and of sharing code into different operations. `git-commit` records history, `git-pull`/`git-push` shares code.
Philip Potter
+2  A: 

C++ comments are not allowed as per the MISRA-C 2004 standard. Certain industries (automotive, specifically) prize MISRA compliant code and therefore, C++ comments are not allowed. I believe the same goes for other static code checking tools such as LDRA, etc...

This doesn't make them inherently bad, but it does mean that if you get into certain industries and want to work professionally, you will be actively discouraged from using C++ style comments.

dls
+1 very interesting issue you've raised.
Philip Potter
A: 

This really shouldn't be of any concern these days, unless you're maintaining code for written specifically to compile with ancient compilers and the likes.

nj