The name of the programming language C++ derives from the parent language C and the ++ operator (it should arguably be ++C) and, hence, the expression C++ may naturally occur in C++ programs. I was wondering whether you can write a valid C++ program using the 2011 standard (without extensions) and containing the expression C++11 not within quotes and after pre-processing (note: edited the requirement, see also answer).
Obviously, if you could write a C++ program prior to the 2011 standard with the expressions C++98 or C++03, then the answer is a trivial yes. But I don't think that was possible (though I don't really know). So, can it be done with the new armory of C++11?
NO if we require the characters C++11 to be outside any literal, after preprocessing -- because at translation phase 7 the three tokens will be identifier, ++ and integer-literal
The first two tokens are a postfix-expression, the later is a primary.
There is no reduction in the grammar that can contain these two nonterminals in sequence, so any program containing C++11 will fail syntax analysis.
However, if you do not consider character literals to be strings, then the answer is YES as you can contain it in a wide character literal:
int main()
{
wchar_t x = L'C++11';
}
which does not use the preprocessor or a string literal, and the construct is required to be supported by the standard:
The value of a wide-character literal containing multiple c-chars is implementation-defined.
So, can it be done with the new armory of C++11?
No.
Define “valid C++ program”.
The C++ standard defines a “well-formed C++ program” as “a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule”. This leaves open the possibility of C++ programs that are not well-formed. (C explicitly has the notion of programs that are conforming but not strictly conforming, e.g., that use extensions of a particular compiler.)
If you consider it valid to use extensions, then you can implement a C++ compiler that permits C++11 in some context.
Related
I'm asking this question because I'm updating my C and C++ course materials and I've had past students ask about it...
From ISO/IEC 9899:2017 section 6.5 Expressions ¶1 (and similar in the C++ standard):
"An expression is a sequence of operators and operands that specifies computation of a value, or that designates an object or a function, or that generates side effects, or that performs a combination thereof. …"
Because the standards writers obviously choose their words carefully, the use of the phrase "sequence of operators and operands" seems potentially misleading to me. It seems to indicate that to be considered an expression there must be more than one operator and also more than one operand. Thus, literals like 123 or variables like XYZ would not be considered expressions because there is no operator, and they certainly can't be considered operands if there is no operator.
However, if 123 and XYZ actually are expressions, wouldn't replacing the phrase "sequence of operators and operands" with "sequence of one or more characters" or something similar be more accurate?
Please tell me what I am misinterpreting about what the standard is stating.
and similar in the C++ standard
I don't know about the C standard, but the C++ standard puts this statement in a non-normative notation. It has no normative value to C++, so it should be read as colloquial.
You forgot of Primary expressions that have a separate definition in (6.5.1).
You just confused different entities; the definition you provided describes exactly what it should describe.
6.5.1 Primary expressions
Syntax:
primary-expression:
identifier
constant
string-literal
(expression)
Yes, the definition of "expression" in the C standard is incomplete -- but not in a way that causes any actual problems (other than to picky people like me).
The word "expression" in the text you quoted is in italics, which means that that is the official definition of the term. It's clear from other parts of the standard that 123, for example, is an expression: it's a decimal-constant, which is an integer-constant, which is a constant, which is a primary-expression`, which is a postfix-expression, which (skipping multiple steps) is an expression.
It is not "a sequence of operators and operands". There is no operator, which implies that 123 is not an operand (this can be demonstrated by referring to the definitions of operator and operand elsewhere in the standard).
In practice, I've never heard of anyone, either a compiler implementer or a C programmer, having any real difficulty because of this incomplete definition. Compiler implementers refer to the language grammar. C programmers probably get a pretty good idea of what an "expression" is before reading the standard.
I'd like to see the definition of expression updated in a new edition of the standard. A definition that refers to the grammar rather than attempting an English description would IMHO be an improvement.
But if it isn't updated, we'll all keep using expressions without any problems.
As for C++, Nicol Bolas's answer correctly points out that the C++ standard doesn't have a formal definition of "expression" like the C standard does. It does have similar wording at the top of Clause 8: "An expression is a
sequence of operators and operands that specifies a computation." -- but the word "expression" is not in italics and that sentence is part of a "Note", and is therefore non-normative. In C++, the standard defines expressions syntactically.
I was writing this answer and I quoted from http://en.cppreference.com/w/cpp/string/byte/tolower#Parameters
Is not representable as unsigned char and does not equal EOF, the behavior is undefined
When I went to inspect the edit that had added this phrase I found that the author's comment:
Can't use negative signed chars with any ctype.h function per C99 7.4/1
The author is citing from the C99 standard in C++ documentation. Is that valid? I couldn't find anything on the definition of this function in the C++ standard, so I must assume that it is valid.
But this concerns me for 2 reasons:
How would I know what version of the C standard the C++ standard depends upon?
There are lists of the discrepancies between C and C++ everywhere. If I'm looking at the C standard with reference to C++ how could I possibly know whether the area I'm looking at has been overridden?
For the first question:
The C++ standard explicitly lists the C standard(s) on which it depends in its Normative references section. For C++14, [intro.refs] 1.2/1 happens to list C 99:
ISO/IEC 9899:1999, Programming languages — C
ISO/IEC 9899:1999/Cor.1:2001(E), Programming languages — C, Technical Corrigendum 1
ISO/IEC 9899:1999/Cor.2:2004(E), Programming languages — C, Technical Corrigendum 2
ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3
For the second question:
The C++ standard does not implicitly incorporate any parts of the C standard; all references to the C standard are explicit. A good source of information on where C++ deviates from C is Annex C, "Compatibility" of the C++ standard, particularly C.1 [diff.iso].
Additionally, references to the C standard library are scattered throughout the description of the C++ standard library (chapters 17–30 in C++14). Of particular interest can be:
17.2 [library.c], which describes the basic inclusion of the C standard library
Chapter 18 [language.support], which describes many of the <c:::> headers of the C++ standard library (those which offer the C standard library functionality).
How would I know what version of the C standard the C++ standard depends upon?
In C++ 14, it's ISO/IEC 9899:1999 (plus three corrigendums, so C99 in essence) as stated in 1.2 [intro.refs] in N4140. In C++98, it was C90, in C++17, it probably will be C11, but the C++ standard will always make that explicit.
If I'm looking at the C standard with reference to C++ how could I possibly know whether the area I'm looking at has been overridden?
You look in the C++ standard, it either explicitly imports the C definitions minus restrict or any C behavior it wants or makes explicit modifications.
Usually, reading good documentation instead of the standard itself will serve you just fine.
To address your initial question:
The author is citing from the C99 standard in C++ documentation. Is that valid?
Yes, because
1
Tables 74 [contains std::tolower, me], 75, 76, 77, 78, and 79 describe headers <cctype>, <cwctype>, <cstring>, <cwchar>, <cstdlib>
(character conversions), and <cuchar>, respectively.
2
The contents of these headers shall be the same as the Standard C Library headers <ctype.h>, <wctype.h>,
<string.h>, <wchar.h>, and <stdlib.h> and the C Unicode TR header <uchar.h>, respectively, with the
following modifications [none of those apply to std::tolower, me]:
21.8 [c.strings] in N4140
The edit is correct and this particular text has been in the standard since C90.
From C90 4.3
The header declares several functions useful for testing
and mapping characters. In all cases the argument is an int , the
value of which shall be representable as an unsigned char or shall
equal the value of the macro EOF . If the argument has any other
value, the behavior is undefined.
From C11 7.4/1
The header declares several functions useful for classifying
and mapping characters. In all cases the argument is an int, the
value of which shall be representable as an unsigned char or shall
equal the value of the macro EOF. If the argument has any other value,
the behavior is undefined.
Identical text; C has always been like this. So it doesn't matter which C version your particular C++ version uses, because all C versions are equivalent.
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++?
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).
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.
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.
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.
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.
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.
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".
This question already has answers here:
Where is C not a subset of C++? [closed]
(11 answers)
Closed 7 years ago.
I have read in tutorials that C++ contains the entire C programming language.
However I have also read, in places like this that
If you learn C++ you will eventually learn most of C with some differences between the languages that you will learn over time.
So my question is only this:
If I know C++ very well, will I eventually learn the "real" C language (without any "differences") because the full C90 language is included in C++11?
No, C++ is not a superset of the C language. While C++ contains a large part of C, there are subtle difference that can bite you badly where you least expect them. Here are some examples:
C has the concept of tentative definitions which doesn't exist in C++.
C does not require explicit conversion on assignment of void pointers to variables of concrete type.
C has different rules regarding const propagation.
C has something called the “implicit int rule,” which, although abolished with C99, appears some times and needs to be considered.
The C preprocessor has some features the C++ preprocessor does not have.
The C language has two styles of function definition, K&R-style and Stroustrup-style. C++ only has Stroustrup-style.
The lexing rules for C and C++ are different with neither being a subset of the other
C and C++ have different sets of reserved words. This can cause weird errors because an identifier is not allowed in the other language.
While C++ took almost all features from ANSI C (C89), many features were added to C in subsequent standard revisions that are not available in C++.
C++ has a different syntax, even for some parts that aren't new. For example, a ? b : c = d is a syntax error in C but parsed as a ? b : (c = d) in C++.
C guarantees that &*E is exactly identical to E, even if E is a null pointer. C++ has no such guarantee.
In C, a string literal initializing an array of characters can initialize an array that is at least as long as the string without the trailing \0 byte. (i.e. char foo[3] = "bar" is legal). In C++, the array has to be at least as long as the string including the trailing \0 byte.
In C, a character literal like 'A' has type int. In C++, it has type char.
C has a special rule to make type punning through unions to be legal. C++ lacks this language, making code such as
union intfloat {
int i;
float f;
} fi;
fi.f = 1.0;
printf("%d\n", fi.i);
undefined behaviour.
If I know C++ very well, will I eventually learn the "real" C language (without any "differences")
If you learn C++ properly, you will probably not need to use many of the standard techniques used in C. Theoretically you could program almost anything C in C++, with exceptions that have already been introduced. However, in reality, you wouldn't - or shouldn't. This is because C++ is a different language that provides a very different set of tools when used optimally.
Aside from the very basic elements like general syntax and fundamental types, these are two separately evolving languages, and they should be approached (learned, programmed) as such.
In broad terms, the C++ language is essentially C with a whole bunch of object oriented stuff added. Nearly all the code you could write in C will also compile and run just fine in C++.
However, there are a few corners of the languages where there are differences. The number of these have been slowly growing over time, but the languages aren't changing rapidly enough for that to be a significant problem.
If you only learn C++, then yes, you will eventually learn almost all aspects of the C language too. If you become expert in C++, then you will be able to identify and understand the places where small differences between the similar parts of C and C++ exist.
I am not sure what "differences" might exist...
For example like this one:
In C:
void foo() means "a function foo taking an unspecified number of arguments of unspecified type"
[...]
In C++:
void foo() means "a function foo taking no arguments"
I am trying to calculate the Greatest Common Denominator of two integers.
C Code:
#include <stdio.h>
int gcd(int x, int y);
int main()
{
int m,n,temp;
printf("Enter two integers: \n");
scanf("%d%d",&m,&n);
printf("GCD of %d & %d is = %d",m,n,gcd(m,n));
return 0;
}
int gcd(int x, int y)
{
int i,j,temp1,temp2;
for(i =1; i <= (x<y ? x:y); i++)
{
temp1 = x%i;
temp2 = y%i;
if(temp1 ==0 and temp2 == 0)
j = i;
}
return j;
}
In the if statement, note the logical operator. It is and not && (by mistake). The code works without any warning or error.
Is there an and operator in C? I am using orwellDev-C++ 5.4.2 (in c99 mode).
&& and and are alternate tokens and are functionally same, from section 2.6 Alternative tokens from the C++ draft standard:
Alternative Primary
and &&
Is one of the entries in the Table 2 - Alternative tokens and it says in subsection 2:
In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling. The set of alternative tokens is defined in Table 2.
As Potatoswatter points out, using and will most likely confuse most people, so it is probably better to stick with &&.
Important to note that in Visual Studio is not complaint in C++ and apparently does not plan to be.
Edit
I am adding a C specific answer since this was originally an answer to a C++ question but was merged I am adding the relevant quote from the C99 draft standard which is section 7.9 Alternative spellings <iso646.h> paragraph 1 says:
The header defines the following eleven macros (on the left) that expand
to the corresponding tokens (on the right):
and includes this line as well as several others:
and &&
We can also find a good reference here.
Update
Looking at your latest code update, I am not sure that you are really compiling in C mode, the release notes for OrwellDev 5.4.2 say it is using GCC 4.7.2. I can not get this to build in either gcc-4.7 nor gcc-4.8 using -x c to put into C language mode, see the live code here. Although if you comment the gcc line and use g++ it builds ok. It also builds ok under gcc if you uncomment #include <iso646.h>
Check out the page here iso646.h
This header defines 11 macro's that are the text equivalents of some common operators.
and is one of the defines.
Note that I can only test this for a C++ compiler so I'm not certain if you can use this with a strict C compiler.
EDIT I've just tested it with a C compiler here and it does work.
and is just an alternative token for &&.
We can easily quote the standard here :
2.6 Alternative tokens [lex.digraph]
In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling. The set of alternative tokens is defined in Table 2.
In table 2 :
Alternative | Primary
and | &&
But I suggest you to use &&. People used to C/C++ may get confused by and...
Since it is merged now, we are talking also about C, you can check this page ciso646 defining the alternatives tokens.
This header defines 11 macro constants with alternative spellings for those C++ operators not supported by the ISO646 standard character set.
From the C99 draft standard :
7.9 Alternative spellings <iso646.h>
The header defines the following eleven macros (on the left) that expand
to the corresponding tokens (on the right):
and &&
Basically and is just the text version of && in c.
You do however need to #include <iso646.h>. or it isn't going to compile.
You can read more here:
http://msdn.microsoft.com/en-us/library/c6s3h5a7%28v=vs.80%29.aspx
If the code in your question compiles without errors, either you're not really compiling in C99 mode or (less likely) your compiler is buggy. Or the code is incomplete, and there's a #include <iso646.h> that you haven't shown us.
Most likely you're actually invoking your compiler in C++ mode. To test this, try adding a declaration like:
int class;
A C compiler will accept this; a C++ compiler will reject it as a syntax error, since class is a keyword. (This may be a bit more reliable than testing the __cplusplus macro; a misconfigured development system could conceivably invoke a C++ compiler with the preprocessor in C mode.)
In C99, the header <iso646.h> defines 11 macros that provide alternative spellings for certain operators. One of these is
#define and &&
So you can write
if(temp1 ==0 and temp2 == 0)
in C only if you have a #include <iso646.h>; otherwise it's a syntax error.
<iso646.h> was added to the language by the 1995 amendment to the 1990 ISO C standard, so you don't even need a C99-compliant compiler to use it.
In C++, the header is unnecessary; the same tokens defined as macros by C's <iso646.h> are built-in alternative spellings. (They're defined in the same section of the C++ standard, 2.6 [lex.digraph], as the digraphs, but a footnote clarifies that the term "digraph" doesn't apply to lexical keywords like and.) As the C++ standard says:
In all respects of the language, each alternative token behaves the
same, respectively, as its primary token, except for its spelling.
You could use #include <ciso646> in a C++ program, but there's no point in doing so (though it will affect the behavior of #ifdef and).
I actually wouldn't advise using the alternative tokens, either in C or in C++, unless you really need to (say, in the very rare case where you're on a system where you can't easily enter the & character). Though they're more readable to non-programmers, they're likely to be less readable to someone with a decent knowledge of the C and/or C++ language -- as demonstrated by the fact that you had to ask this question.
It is compiling to you because I think you included iso646.h(ciso646.h) header file.
According to it and is identical to &&. If you don't include that it gives compiler error.
The and operator is the text equivalent of && Ref- AND Operator
The or operator is the text equivalent of || Ref.- OR Operator
So resA and resB are identical.
&& and and are synonyms and mean Logical AND in C++. For more info check Logical Operators in C++ and Operator Synonyms in C++.