ChatGPT解决这个技术问题 Extra ChatGPT

Can code that is valid in both C and C++ produce different behavior when compiled in each language?

c++ c

C and C++ have many differences, and not all valid C code is valid C++ code. (By "valid" I mean standard code with defined behavior, i.e. not implementation-specific/undefined/etc.)

Is there any scenario in which a piece of code valid in both C and C++ would produce different behavior when compiled with a standard compiler in each language?

To make it a reasonable/useful comparison (I'm trying to learn something practically useful, not to try to find obvious loopholes in the question), let's assume:

Nothing preprocessor-related (which means no hacks with #ifdef __cplusplus, pragmas, etc.)

Anything implementation-defined is the same in both languages (e.g. numeric limits, etc.)

We're comparing reasonably recent versions of each standard (e.g. say, C++98 and C90 or later) If the versions matter, then please mention which versions of each produce different behavior.

By the way, it can be useful to program in a dialect which is C and C++ at the same time. I've done this in the past and one one current project: the TXR language. Interestingly, the developers of the Lua language did the same thing, and they call this dialect "Clean C". You get the benefit of better compile time checking and possibly additional useful diagnostics from C++ compilers, yet retain the C portability.
I merged the older question into this question since this has more views and upvoted answers. This is still an example of a non-constructive question, but it's quite borderline since yes, it does teach SO users something. I'm closing it as not constructive only to reflect the state of the question before the merge. Feel free to disagree and re-open.
Voting to reopen as I think it can be objectively answered with a "yes" followed by an example (as proved below). I think it is constructive in that people can learn relevant behaviour from it.
@AndersAbel The pure number of answers, all of which are correct, demonstrates unambiguously that it remains a make-a-list question. There was no way you could have asked this question without getting a list.
@dmckee For what it's worth, I agree with you. However, the C++ tag people are... Shall we say... feisty.

A
Ayxan Haqverdili

Here is an example that takes advantage of the difference between function calls and object declarations in C and C++, as well as the fact that C90 allows the calling of undeclared functions:

#include <stdio.h>

struct f { int x; };

int main() {
    f();
}

int f() {
    return printf("hello");
}

In C++ this will print nothing because a temporary f is created and destroyed, but in C90 it will print hello because functions can be called without having been declared.

In case you were wondering about the name f being used twice, the C and C++ standards explicitly allow this, and to make an object you have to say struct f to disambiguate if you want the structure, or leave off struct if you want the function.


Strictly speaking under C this will not compile, because the declaration of "int f()" is after the definition of "int main()" :)
@Sogartar, really? codepad.org/STSQlUhh C99 compilers will give you a warning, but they'll still let you compile it.
@Sogartar in C functions are allowed to be implicitly declared.
@AlexB Not in C99 and C11.
@user529758 - They may well be C99 compilers. A C99 which detects undeclared identifiers is required to treat it as a syntax error, and is required to "emit a diagnostic"; it is not required to fail to compile the file.
A
Antti Haapala -- Слава Україні

For C++ vs. C90, there's at least one way to get different behavior that's not implementation defined. C90 doesn't have single-line comments. With a little care, we can use that to create an expression with entirely different results in C90 and in C++.

int a = 10 //* comment */ 2 
        + 3;

In C++, everything from the // to the end of the line is a comment, so this works out as:

int a = 10 + 3;

Since C90 doesn't have single-line comments, only the /* comment */ is a comment. The first / and the 2 are both parts of the initialization, so it comes out to:

int a = 10 / 2 + 3;

So, a correct C++ compiler will give 13, but a strictly correct C90 compiler 8. Of course, I just picked arbitrary numbers here -- you can use other numbers as you see fit.


WHOA this is mind-blowing!! Of all possible things I would never have thought comments could be used to change behavior haha. +1
even without the 2, it would read as 10 / + 3 which is valid (unary +).
Now for fun, modify it so that C and C++ both calculate different arithmetic expressions the evaluate to the same result.
@RyanThompson Trivial. s/2/1/
@Mehrdad Am I wrong or comments are preprocessor-related? They should thus be excluded as a possible answer from your question! ;-)
D
Donald Duck

The following, valid in C and C++, is going to (most likely) result in different values in i in C and C++:

int i = sizeof('a');

See Size of character ('a') in C/C++ for an explanation of the difference.

Another one from this article:

#include <stdio.h>

int  sz = 80;

int main(void)
{
    struct sz { char c; };

    int val = sizeof(sz);      // sizeof(int) in C,
                               // sizeof(struct sz) in C++
    printf("%d\n", val);
    return 0;
}

Definitely wasn't expecting this one! I was hoping for something a little more dramatic but this is still useful, thanks. :) +1
+1 the second example is a good one for the fact that C++ doesn't require struct before struct names.
@Andrey I thought the same a while ago and tested it and it worked on GCC 4.7.1 without the std, contrary to my expectation. Is that a bug in GCC?
@SethCarnegie: A non-conforming program need not fail to work, but it is not guaranteed to work either.
struct sz { int i[2];}; would mean that C and C++ have to produce different values. (Whereas a DSP with sizeof(int) == 1, could produce the same value).
v
vonbrand

C90 vs. C++11 (int vs. double):

#include <stdio.h>

int main()
{
  auto j = 1.5;
  printf("%d", (int)sizeof(j));
  return 0;
}

In C auto means local variable. In C90 it's ok to omit variable or function type. It defaults to int. In C++11 auto means something completely different, it tells the compiler to infer the type of the variable from the value used to initialize it.


@SethCarnegie: Yeah, it's a storage class; it's what happens by default when you omit it, so no one used it, and they changed its meaning. I think it's int by default. This is clever! +1
@KeithThompson Eh? C11 still has auto, which has been in C since its conception.
C11 does not have implicit-int.
@KeithThompson Ah, I guess you mean the inferred int. Still, in the real world, where there is tons of legacy code and the market leader still hasn't implemented C99 and has no intent to do so, talk of "an obsolete version of C" is absurd.
"Every variable MUST have an explicit storage class. Yours truly, upper management."
g
godlygeek

Another example that I haven't seen mentioned yet, this one highlighting a preprocessor difference:

#include <stdio.h>
int main()
{
#if true
    printf("true!\n");
#else
    printf("false!\n");
#endif
    return 0;
}

This prints "false" in C and "true" in C++ - In C, any undefined macro evaluates to 0. In C++, there's 1 exception: "true" evaluates to 1.


Interesting. Does anyone know the rationale behind this change?
because "true" is a key word/valid value, so it is evaluated to true like any "true value" (so like any positive integer). You can still do #define true false to print "false" in C++ too ;)
#define true false ಠ_ಠ
@DarioOO won't such redefinition result in UB?
@DarioOO: Yes, you are wrong. Re-definition of keywords is not allowed, punishment left to fate (UB). The preprocessor being a separate phase of compilation not withstanding.
K
Kirill Kobelev

Per C++11 standard:

a. The comma operator performs lvalue-to-rvalue conversion in C but not C++:

   char arr[100];
   int s = sizeof(0, arr);       // The comma operator is used.

In C++ the value of this expression will be 100 and in C this will be sizeof(char*).

b. In C++ the type of enumerator is its enum. In C the type of enumerator is int.

   enum E { a, b, c };
   sizeof(a) == sizeof(int);     // In C
   sizeof(a) == sizeof(E);       // In C++

This means that sizeof(int) may not be equal to sizeof(E).

c. In C++ a function declared with empty params list takes no arguments. In C empty params list mean that the number and type of function params is unknown.

   int f();           // int f(void) in C++
                      // int f(*unknown*) in C

The first one is also implementation-defined like Alexey's. But +1.
@Seth, All material above is taken directly from Annex C.1 of the C++11 standard.
Yes but it is still implementation-defined. sizeof(char*) could be 100 in which case the first example would produce the same observable behaviour in C and C++ (i.e. though the method of obtaining s would be different, s would end up being 100). The OP mentioned that this type of implementation-defined behaviour was fine as he was just wanting to avoid language-lawyer answers, so the first one is fine by his exception. But the second one is good in any case.
There is an easy fix -- just change the example to: char arr[sizeof(char*)+1]; int s = sizeof(0, arr);
To avoid implementation-defined differences, you could also use void *arr[100]. In this case an element is the same size as a pointer to the same element, so as long as there are 2 or more elements, the array must be larger than the address of its first element.
P
Pavel Chikulaev

This program prints 1 in C++ and 0 in C:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int d = (int)(abs(0.6) + 0.5);
    printf("%d", d);
    return 0;
}

This happens because there is double abs(double) overload in C++, so abs(0.6) returns 0.6 while in C it returns 0 because of implicit double-to-int conversion before invoking int abs(int). In C, you have to use fabs to work with double.


had to debug code of someone else with that issue. Oh How I loved that. Anyway your program is printing 0 in C++ too. C++ have to use the header "cmath" see comparison first one returnin 0 ideone.com/0tQB2G 2nd one returning 1 ideone.com/SLeANo
Glad/sorry to hear that I'm not the only who find this difference via debugging. Just tested in VS2013, an empty with only file with this content will output 1 if extension is .cpp, and 0 if extension is .c. Looks like is included indirectly in VS.
And looks like in VS C++, includes C++ stuff into global namespace, where as for GCC it is not. Unsure which is standard behavior however.
This particular code sample is implementation-dependent: stdlib.h only defines abs(int) and abs(long); the version abs(double) is declared by math.h. So this program may still call the abs(int) version. It's an implementation detail whether stdlib.h also causes math.h to be included. (I think it would be a bug if abs(double) were called, but other aspecs of math.h were not included).
A secondary issue is that although the C++ standard does appear to say that including <math.h> also includes the additional overloads; in practice it turns out that all the major compilers don't include those overloads unless the form <cmath> is used.
A
Adam Rosenfield
#include <stdio.h>

int main(void)
{
    printf("%d\n", (int)sizeof('a'));
    return 0;
}

In C, this prints whatever the value of sizeof(int) is on the current system, which is typically 4 in most systems commonly in use today.

In C++, this must print 1.


Yes, I was actually familiar with this trick, being that 'c' is an int in C, and a char in C++, but it's still good to have it listed here.
That would make an interesting interview question - especially for people that put c/c++ expert on their CVs
Kind of underhanded though. The whole purpose of sizeof is so you don't need to know exactly how large a type is.
In C the value is implementation defined and 1 is a possibility. (In C++ it has to print 1 as stated.)
Actually it has undefined behavior in both cases. %d is not the right format specifier for size_t.
A
Alex B

Another sizeof trap: boolean expressions.

#include <stdio.h>
int main() {
    printf("%d\n", (int)sizeof !0);
}

It equals to sizeof(int) in C, because the expression is of type int, but is typically 1 in C++ (though it's not required to be). In practice they are almost always different.


One ! should be enough for a bool.
!! is the int to boolean conversion operator :)
sizeof(0) is 4 in both C and C++ because 0 is an integer rvalue. sizeof(!0) is 4 in C and 1 in C++. Logical NOT operates on operands of type bool. If the int value is 0 it is implicitly converted to false (a bool rvalue), then it is flipped, resulting in true. Both true and false are bool rvalues in C++ and the sizeof(bool) is 1. However in C !0 evaluates to 1, which is an rvalue of type int. C programming language has no bool data type by default.
P
Peter Mortensen

An old chestnut that depends on the C compiler, not recognizing C++ end-of-line comments...

...
int a = 4 //* */ 2
        +2;
printf("%i\n",a);
...

D
Donald Duck

The C++ Programming Language (3rd Edition) gives three examples:

sizeof('a'), as @Adam Rosenfield mentioned; // comments being used to create hidden code: int f(int a, int b) { return a //* blah */ b ; } Structures etc. hiding stuff in out scopes, as in your example.


J
Johannes Schaub - litb

Another one listed by the C++ Standard:

#include <stdio.h>

int x[1];
int main(void) {
    struct x { int a[2]; };
    /* size of the array in C */
    /* size of the struct in C++ */
    printf("%d\n", (int)sizeof(x)); 
}

so you get padding differences ?
ah sorry i got it, there is another x at the top. i thought you said "the array a".
M
M.M

Inline functions in C default to external scope where as those in C++ do not.

Compiling the following two files together would print the "I am inline" in case of GNU C but nothing for C++.

File 1

#include <stdio.h>

struct fun{};

int main()
{
    fun();  // In C, this calls the inline function from file 2 where as in C++
            // this would create a variable of struct fun
    return 0;
}

File 2

#include <stdio.h>
inline void fun(void)
{
    printf("I am inline\n");
} 

Also, C++ implicitly treats any const global as static unless it is explicitly declared extern, unlike C in which extern is the default.


I really don't think so. Probably you have missed the point. It's not about definition of struct st which is merely used to make the code valid c++. The point is that it highlights different behavior of inline functions in c vs c++. Same applies to extern. None of these is discussed in any of the solutions.
What is the different behavior of inline functions and extern that is demonstrated here?
It is written pretty clearly. "Inline functions in c default to external scope where as those in c++ are not (code shows that). Also C++ implicitly treats any const global as file scope unless it is explicitly declared extern, unlike C in which extern is the default. A similar example can be created for that". I am puzzled - Is it not understandable?
@fayyazkl The behaviour shown is only because of the difference of lookup (struct fun vs fn) and has nothing to do whether the function is inline. The result is identical if you remove inline qualifier.
In ISO C this program is ill formed: inline was not added until C99, but in C99 fun() may not be called without a prototype in scope. So I assume this answer only applies to GNU C.
佚名
struct abort
{
    int x;
};

int main()
{
    abort();
    return 0;
}

Returns with exit code of 0 in C++, or 3 in C.

This trick could probably be used to do something more interesting, but I couldn't think of a good way of creating a constructor that would be palatable to C. I tried making a similarly boring example with the copy constructor, that would let an argument be passed, albeit in a rather non-portable fashion:

struct exit
{
    int x;
};

int main()
{
    struct exit code;
    code.x=1;

    exit(code);

    return 0;
}

VC++ 2005 refused to compile that in C++ mode, though, complaining about how "exit code" was redefined. (I think this is a compiler bug, unless I've suddenly forgotten how to program.) It exited with a process exit code of 1 when compiled as C though.


Your second example using exit, doesn't compile on gcc or g++, unfortunately. It's a good idea, though.
exit(code) is a valid declaration of a variable code of type exit, apparently. (See "most vexing parse", which is a different but similar issue).
w
wefwefa3
#include <stdio.h>

struct A {
    double a[32];
};

int main() {
    struct B {
        struct A {
            short a, b;
        } a;
    };
    printf("%d\n", sizeof(struct A));
    return 0;
}

This program prints 128 (32 * sizeof(double)) when compiled using a C++ compiler and 4 when compiled using a C compiler.

This is because C does not have the notion of scope resolution. In C structures contained in other structures get put into the scope of the outer structure.


This one is interesting! (I think you mean 32*sizeof(double) rather than 32 though :))
note that you're getting UB by printing size_t with %d
u
user23614

Don't forget the distinction between the C and C++ global namespaces. Suppose you have a foo.cpp

#include <cstdio>

void foo(int r)
{
  printf("I am C++\n");
}

and a foo2.c

#include <stdio.h>

void foo(int r)
{
  printf("I am C\n");
}

Now suppose you have a main.c and main.cpp which both look like this:

extern void foo(int);

int main(void)
{
  foo(1);
  return 0;
}

When compiled as C++, it will use the symbol in the C++ global namespace; in C it will use the C one:

$ diff main.cpp main.c
$ gcc -o test main.cpp foo.cpp foo2.c
$ ./test 
I am C++
$ gcc -o test main.c foo.cpp foo2.c
$ ./test 
I am C

You mean the linkage specification?
name mangling. C++ names have prefixes and suffixes while C not
Name mangling is not a part of the C++ specification. Is it prohibited in C?
This is undefined behaviour (multiple definition of foo). There are not separate "global namespaces".
A
Antti Haapala -- Слава Україні
int main(void) {
    const int dim = 5; 
    int array[dim];
}

This is rather peculiar in that it is valid in C++ and in C99, C11, and C17 (though optional in C11, C17); but not valid in C89.

In C99+ it creates a variable-length array, which has its own peculiarities over normal arrays, as it has a runtime type instead of compile-time type, and sizeof array is not an integer constant expression in C. In C++ the type is wholly static.

If you try to add an initializer here:

int main(void) {
    const int dim = 5; 
    int array[dim] = {0};
}

is valid C++ but not C, because variable-length arrays cannot have an initializer.


G
Galaxy

This concerns lvalues and rvalues in C and C++.

In the C programming language, both the pre-increment and the post-increment operators return rvalues, not lvalues. This means that they cannot be on the left side of the = assignment operator. Both these statements will give a compiler error in C:

int a = 5;
a++ = 2;  /* error: lvalue required as left operand of assignment */
++a = 2;  /* error: lvalue required as left operand of assignment */

In C++ however, the pre-increment operator returns an lvalue, while the post-increment operator returns an rvalue. It means that an expression with the pre-increment operator can be placed on the left side of the = assignment operator!

int a = 5;
a++ = 2;  // error: lvalue required as left operand of assignment
++a = 2;  // No error: a gets assigned to 2!

Now why is this so? The post-increment increments the variable, and it returns the variable as it was before the increment happened. This is actually just an rvalue. The former value of the variable a is copied into a register as a temporary, and then a is incremented. But the former value of a is returned by the expression, it is an rvalue. It no longer represents the current content of the variable.

The pre-increment first increments the variable, and then it returns the variable as it became after the increment happened. In this case, we do not need to store the old value of the variable into a temporary register. We just retrieve the new value of the variable after it has been incremented. So the pre-increment returns an lvalue, it returns the variable a itself. We can use assign this lvalue to something else, it is like the following statement. This is an implicit conversion of lvalue into rvalue.

int x = a;
int x = ++a;

Since the pre-increment returns an lvalue, we can also assign something to it. The following two statements are identical. In the second assignment, first a is incremented, then its new value is overwritten with 2.

int a;
a = 2;
++a = 2;  // Valid in C++.

There's no "valid in C" here.
D
Daniel Frużyński

Empty structures have size 0 in C and 1 in C++:

#include <stdio.h>

typedef struct {} Foo;

int main()
{
    printf("%zd\n", sizeof(Foo));
    return 0;
}

No, the difference is that C does not have empty structures, except as a compiler extension, i.e. this code does not match "is valid in both C and C++"