-4

Is there any difference between a commenting style between C(/*..*/) and C++(//)?

MISRA C:2004 says

Rule 2.2 (required): Source code shall only use /* … */ style comments.

Note: This Rule is revoked for MISRA C:2012 when support for C99 was added

MISRA C++ says

Rule 2.7.1 (required): The character sequence /* shall not be used with c style comments.

Rule 2.7.3 says suggested comment as // for c++

Can any one explain why MISRA says to use /* in C and // in C++?

Andrew
  • 2,046
  • 1
  • 24
  • 37
Embedded C
  • 1,448
  • 3
  • 16
  • 29
  • 1
    for those who knows about misra they can answer. others refer that and giver answer and comments. understand the my question – Embedded C Jan 29 '16 at 13:06
  • 2
    Please quote the standards verbatim. There is no chance that MISRA literally says "suggested comment as // for c++". And I suspect 2.7.1 says "within", not "with". – molbdnilo Jan 29 '16 at 13:12
  • 1
    @molbdnilo I cannot share the misra guidance, you can google it and see it says. that's why i am pointing the rules – Embedded C Jan 29 '16 at 13:14

7 Answers7

18

The MISRA C clause you quote requires that "line comments" of the form

//    This is a line comment

not be used, in favour of a "C-style" comment of the form

/*   Original C style comment
          Can extend across multiple lines
*/

This allows older compilers to be used, since the "line comment" was only introduced in 1999, and was only available with some compilers before then as a non-standard extension.

The MISRA C++ clause you quote (from memory, there is a similar one in MISRA C) requires that the "original C-style comment" shall not be nested. So, this is discouraged

/*   Warning:   non-standard nesting of comment
     /*   Nested comment
     */
*/

This is discouraged because support for it is not standard, but some compilers can be configured to support it. Code which uses "nested comments" can therefore behave differently (including compiling with one compiler, but not with another) and in unintended ways. However, code without nested comments will compile as intended, regardless of whether or not the compiler supports nested comments.

There isn't a problem with nesting of "line comments", since the // causes the compiler to ignore everything to end of line. This is okay in C++, since (unlike C) all C++ versions (even pre-standard) support "line comments". (This is not necessarily true if digraphs or trigraphs are used, but MISRA also discourages using them).

Peter
  • 35,646
  • 4
  • 32
  • 74
7

Rule 2.2 means C only allows /**/ comments, while rules 2.7.1 tells not to nest C comments, by forbidding the use /* in a C comment. They are unrelated.

Cecilio Pardo
  • 1,717
  • 10
  • 13
  • The first part is for C, the second part for C++. Which is ever so slightly muddying the waters: does this imply that you *are* allowed to nest C comments in **C** but not, per 2.7.1, in **C++**? – Jongware Jan 29 '16 at 13:10
  • 1
    @Jongware For C there is rule 2.3, which is the same (I guess, I haven't got MISRA C++ docs). – user694733 Jan 29 '16 at 13:11
  • 1
    @Cecillio yeah, i did not include it now check the question it is related – Embedded C Jan 29 '16 at 13:12
  • 2
    No, they are not related. First rule is about forbidding // in C, second rule is about forbidding nesting. – Cecilio Pardo Jan 29 '16 at 13:13
7

C89 had only /* ... */ for comments. But C++ style comments // .. were added to C in C99. I think MISRA simply attempts to keep it consistent so that the C++ style comments do not become an issue if you are compiling the C code in C89/C90.

But this rarely matters anymore as both styles of comments are supported in both modern C and C++.

You can read the MISRA rationale for the reasoning:

MISRA-C-2004 rationale:

Rule 2.3 (required): The character sequence /* shall not be used within a comment.

C does not support the nesting of comments even though some compilers support this as a language extension. A comment begins with /* and continues until the first */ is encountered. Any /* occurring inside a comment is a violation of this rule.

Consider the following code fragment: /* some comment, end comment marker accidentally omitted <> Perform_Critical_Safety_Function(X); /* this comment is not compliant */

In reviewing the page containing the call to the function, the assumption is that it is executed code. Because of the accidental omission of the end comment marker, the call to the safety critical function will not be executed.

MISRA-C++ 2008 rationale:

Rule 2-7-1 The character sequence /* shall not be used within a C-style comment.

C++ does not support the nesting of C-style comments even though some compilers support this as a non-portable language extension. A comment beginning with /* continues until the first */ is encountered. Any /* occurring inside a comment is a violation of this rule.

P.P
  • 117,907
  • 20
  • 175
  • 238
4

Although // were an incredibly common non-standard extension to C90 compilers, it was never allowed by the C90 standard. The rationale for the MISRA rule is that you should follow the applicable language standard.

So it's quite simple:

  • MISRA-C:2004 is for C90 which only allowed /* */ comments.
  • MISRA-C++:2008 is for C++, which allows // comments (no matter C++ version)
  • MISRA-C:2012 is for C99 which allows // comments.

Because of the above, the rule you refer to has been removed in MISRA-C:2012. Consider upgrading to the 2012 MISRA version, as it has been improved in many ways.

Lundin
  • 195,001
  • 40
  • 254
  • 396
2

In short, those standards are to help the programmers from getting inconsistent compiler behaviors due to the comment style when they compile their codes using different compiler standards.

This is the rationale behind the standards.


More elaborated answer:

This is because the // line comment is not supported before C99 standard. While MISRA-C 2004 document is created to support C89/C90 standard.

Rule 2.2 (required): Source code shall only use /* … */ style comments.

This excludes the use of // C99 style comments and C++ style comments, since these are not permitted in C90. Many compilers support the // style of comments as an extension to C90. The use of // in preprocessor directives (e.g. #define) can vary. Also the mixing of /* … */ and // is not consistent. This is more than a style issue, since different (pre C99) compilers may behave differently

Check Lundin's answer on this post. Also, check this SO post on C line commenting before C99.

Thus, that explain why the MISRA-C 2004 clause you post requires /* to be used.

With the same idea, the MISRA-C++ 2008 standard discourages the use of /* - C-Style (multiline) comment - in C++ since some compilers may generate errors. It encourages to use // since it is the "original" C++ comment style.

Community
  • 1
  • 1
Ian
  • 30,182
  • 19
  • 69
  • 107
2

From MISRA C 2004:

Rule 2.2 (required): Source code shall only use /* … */ style comments.

This excludes the use of // C99 style comments and C++ style comments, since these are not permitted in C90. Many compilers support the // style of comments as an extension to C90. The use of // in preprocessor directives (e.g. #define) can vary. Also the mixing of /* … */ and // is not consistent. This is more than a style issue, since different (pre C99) compilers may behave differently.

I think this explains it all, but I'll still add my explanation with links.

In original C (pre C99), there were no // comments. C++ introduced a double slash comment prefix // as a way to comment single lines.

For more clarity, let's go line by line:

This excludes the use of // C99 style comments and C++ style comments, since these are not permitted in C90.

Nowadays, modern compilers like gcc have started supporting such // in C90 mode also, but will still issue a warning like:

warning: C++ style comments are not allowed in C90

but it is recommended to use /*..*/ comments in C90 C.

Many compilers support the // style of comments as an extension to C90.

That is what I exactly told above, but it is still not recommended to use // in C90 C as the code will not be portable. For example, that code will compile with gcc, but with another compiler which does not have the extension, it will not compile.

The use of // in preprocessor directives (e.g. #define) can vary.

I think the meaning of this is clear. It says that the usage of // is not going to be consistent in preprocessor directives.

Also the mixing of /* ... */ and // is not consistent.

How? This is possible. Like I mentioned above, it varies from compiler to compiler. In C99 C, it will be mostly consistent, but if you're talking about the pre C99 compilers, it matters if they support or not support // comments.

This is more than a style issue, since different (pre C99) compilers may behave differently.

Yes it is. As this is MISRA 2004, which is mainly talking about pre C90 C mainly. This is because most C90 compilers do not support //, and thus you will get an error. If you're using C99, this is invalid.


Questions Expected

Why was there no // in pre C99 C, and then why was it introduced in C++? Is there a specific reason?

C originated from B. B originated from BCPL. // were created during BCPL, and thus BCPl used them. It's successor B started using /*...*/, which were inherited by C. Although, C++ decided to resurrect the BCPL comments, and of course used /*...*/ also. The C-standard at that time took // as a non-standard feature.

When C99 C was introduced, it had the comments //.

What are // and /*...*/ comments called?

// comments are called single-line comments as they can only extend till one line.

/*...*/ comments are called multi-line comments as they can extend upto multiple lines.

Is it compulsory to use only one kind of comment through your source code?

No, you can use any and even both. Although, some people say that using only one type makes the code readable. It is more a matter of opinion.

Is rule 2.2 of MISRA C 2004 outdated?

Kind of. Recently, MISRA 2012 was released which has these changes. Although, if you think that MISRA C 2004 is wrong as it is only concentrating on pre C99, it isn't. I would recommend using MISRA 2012 nowadays.

Community
  • 1
  • 1
Box Box Box Box
  • 5,094
  • 10
  • 49
  • 67
0

Rule 2.7.1 (required): The character sequence /* shall not be used with c style comments.

(emphasis added)

I think you are just misreading the meaning of the word "with" in the above rule and interpreting in the sense "shall not be used for c style comments".

Perhaps the rule would be more clear if the word "within" were used rather than "with".

Chip Grandits
  • 317
  • 1
  • 9
  • Perhaps *within* might have been better... but even when the question was asked, MISRA C:2012 had been around for a few years, and there are no plans to update MISRA C:2004 – Andrew Nov 27 '21 at 07:10