Участник:Joparino/Совместимость C и C++

Языки программирования C и C++ тесно связаны, но имеют существенные различия. C++ создавался как потомок достандартизированного C и был разработан так, чтобы быть в основном совместимым с исходным кодом C того времени. В связи с этим, средства разработки для двух языков (такие, как интегрированные среды разработки и компиляторы) часто интегрировались в один продукт, при этом программист может указать C или C++ в качестве исходного языка.

Однако, C не является подмножеством C++,, поэтому нетривиальные программы на C не будут компилироваться на C++ без изменений. Также, C++ вводит множество возможностей, недоступных в C и на практике почти весь код, написанный на C++, не соответствует коду на C. Однако в этой статье основное внимание уделяется различиям, которые приводят к тому, что соответствующий код C является неправильно написанным (англ. ill-formed) кодом C++ или соответствующим/хорошо написанном (англ. conforming/ill-formed) на обоих языках, но вести себя по-разному на C и C++.

Бьёрн Страуструп, создатель C++, предложил что несовместимость между C и C++ должна быть уменьшена насколько это возможно, чтобы обеспечить максимальную совместимость между двумя языками. Другие утверждают, что, поскольку C и C++ — это два разных языка, совместимость между ними полезна, но не жизненно важна; согласно им, усилия по уменьшению несовместимости не должны препятствовать попыткам улучшить каждый язык в отдельности. Официальное обоснование стандарта 1999 C (C99) "одобрить принцип сохранения наибольшего общего подмножества" между C и C++ "сохраняя при этом различие между ними и позволяя им развиваться отдельно", и заявил, что авторы были "довольны тем, что C++ стал большим и амбициозным языком."

Некоторые нововведения C99 не поддерживаются в текущем стандарте C++ или конфликтуют с особенностями C++, например массивы переменной длины, собственные комплексные типы данных и квалификатор типа restrict. С другой стороны, C99 уменьшил некоторые другие несовместимости по сравнению с C89, включив такие функции C++, как // комментарии и смешанные объявление и код.

Конструкции, допустимые в C, но не в C++

C++ применяет более строгие правила типизации (никаких неявных нарушений системы статических типов), и требования к инициализации (принудительное выполнение во время компиляции, чтобы переменные в области видимости не нарушали инициализацию) чем C, и поэтому некоторый допустимый код C недопустим в C++. Обоснование этого приведено в Приложении C.1 к стандарту ISO C++.

• Одно из часто встречающихся отличий заключается в том, что C более слабо типизирован в отношении указателей. В частности, C позволяет присваивать указатель void* любому типу указателя без приведения, в то время как C++ этого не позволяет; эта идиома часто встречается в коде C, использующем для выделения памяти malloc, или при передаче контекстных указателей на POSIX pthreads API, и другие фреймворки, включающие обратные вызовы. Например, следующее допустимо в C, но не в C++:

  void *ptr;
  /* Неявное преобразование из void* в int* */
  int *i = ptr;
  

  или аналогично:

  int *j = malloc(5 * sizeof *j);     /* Неявное преобразование из void* в int* */
  

  Чтобы заставить код компилироваться как на C, так и на C++, необходимо использовать явное приведение следующим образом (с некоторыми оговорками на обоих языках):

  void *ptr;
  int *i = (int *)ptr;
  int *j = (int *)malloc(5 * sizeof *j);
  

• C++ имеет более сложные правила присваивания указателей, которые добавляют квалификаторы, поскольку он позволяет приводить int ** к const int *const *, но не небезопасное присваивание const int **, в то время как C не допускает ни того, ни другого (хотя компиляторы обычно выдают только предупреждение).
• C++ изменяет некоторые функции стандартной библиотеки языка Си, добавляя дополнительные перегруженные функции с квалификатором типа const, например strchr возвращает char* в C, в то время как C++ поступает так, как если бы были две перегруженные функции const char *strchr(const char *) и char *strchr(char *).
• C++ также более строг в преобразованиях в перечисления: целые числа не могут быть неявно преобразованы в перечисления, как в C. Кроме того, [[Перечисляемый тип#C++ |константные перечисления]] (enum enumerators) всегда имеют тип int в C, тогда как в C++ они являются различными типами и могут иметь размер, отличный от размера int.
• В C++ переменная const должна быть инициализирована; в C это необязательно.
• Компиляторы C++ запрещают goto или switch пересекать инициализацию, как в следующем коде C99:

  void fn(void)
  {
      goto flack;
      int i = 1;
  flack:
      ;
  }
  

• Несмотря на синтаксическую корректность, функция longjmp() приводит к неопределенному поведению в C++, если фреймы стека с перепрыгиванием включают объекты с нетривиальными деструкторами. Реализация C++ может свободно определять поведение таким образом, чтобы вызывались деструкторы. Однако это мешает некоторым видам использования longjmp() , которые в противном случае были бы допустимы, такие как потоков или сопрограмм переключающихся между отдельными стеками вызовов с помощью longjmp() — при переходе из нижнего стека вызовов в верхний в глобальном адресном пространстве деструкторы будут вызываться для каждого объекта в нижнем стеке вызовов. В C такой проблемы не существует. C допускает несколько предварительных определений одной глобальной переменной в одной единице перевода, что недопустимо как нарушение ODR в C+
• C допускает несколько предварительных определений одной глобальной переменной в одной единице трансляции, что недопустимо в C++, так как нарушение правила одного определения (англ. One Definition Rule, ODR).

  int N;
  int N = 10;
  

• В C допустимо объявление нового типа с тем же именем, что и у struct, union или enum, но это недопустимо в C++, потому что в C типы, struct, union, и enum должны указываться всякий раз, когда на тип ссылаются, тогда как в C++ все объявления таких типов неявно содержат typedef.

  enum BOOL {FALSE, TRUE};
  typedef int BOOL;
  

• Non-prototype ("K&R"-style) function declarations are invalid in C++; they are still valid in C, although they have been deemed obsolescent since C's original standardization in 1990. (The term "obsolescent" is a defined term in the ISO C standard, meaning a feature that "may be considered for withdrawal in future revisions" of the standard.) Similarly, implicit function declarations (using functions that have not been declared) are not allowed in C++, and have been invalid in C since 1999.
• In C, a function prototype without parameters, e.g. int foo();, implies that the parameters are unspecified. Therefore, it is legal to call such a function with one or more arguments, e.g. foo(42, "hello world"). In contrast, in C++ a function prototype without arguments means that the function takes no arguments, and calling such a function with arguments is ill-formed. In C, the correct way to declare a function that takes no arguments is by using 'void', as in int foo(void);, which is also valid in C++. Empty function prototypes are a deprecated feature in C99 (as they were in C89).
• In both C and C++, one can define nested struct types, but the scope is interpreted differently: in C++, a nested struct is defined only within the scope/namespace of the outer struct, whereas in C the inner struct is also defined outside the outer struct.
• C allows struct, union, and enum types to be declared in function prototypes, whereas C++ does not.

C99 and C11 added several additional features to C that have not been incorporated into standard C++, such as complex numbers, variable length arrays (note that complex numbers and variable length arrays are designated as optional extensions in C11), flexible array members, the restrict keyword, array parameter qualifiers, compound literals, and designated initializers.

• Complex arithmetic using the float complex and double complex primitive data types was added in the C99 standard, via the _Complex keyword and complex convenience macro. In C++, complex arithmetic can be performed using the complex number class, but the two methods are not code-compatible. (The standards since C++11 require binary compatibility, however.)
• Variable length arrays. This feature leads to possibly non-compile time sizeof operator.

  void foo(size_t x, int a[*]);  // VLA declaration
  void foo(size_t x, int a[x]) 
  {
      printf("%zu\n", sizeof a); // same as sizeof(int*)
      char s[x * 2];
      printf("%zu\n", sizeof s); // will print x*2
  }
  

• The last member of a C99 structure type with more than one member may be a flexible array member, which takes the syntactic form of an array with unspecified length. This serves a purpose similar to variable-length arrays, but VLAs cannot appear in type definitions, and unlike VLAs, flexible array members have no defined size. ISO C++ has no such feature. Example:

  struct X
  {
      int n, m;
      char bytes[];
  }
  

• The restrict type qualifier defined in C99 was not included in the C++03 standard, but most mainstream compilers such as the GNU Compiler Collection, Microsoft Visual C++, and Intel C++ Compiler provide similar functionality as an extension.
• Array parameter qualifiers in functions are supported in C but not C++.

  int foo(int a[const]);     // equivalent to int *const a 
  int bar(char s[static 5]); // annotates that s is at least 5 chars long
  

• The functionality of compound literals in C is generalized to both built-in and user-defined types by the list initialization syntax of C++11, although with some syntactic and semantic differences.

  struct X a = (struct X){4, 6};  // The equivalent in C++ would be X{4, 6}. The C syntactic form used in C99 is supported as an extension in the GCC and Clang C++ compilers.
  foo(&(struct X){4, 6});         // The object is allocated in the stack and its address can be passed to a function. This is not supported in C++.
  
  if (memcmp(d, (int []){8, 6, 7, 5, 3, 0, 9}, n) == 0) {} // The equivalent in C++ would be using digits = int []; if (memcmp(d, digits{8, 6, 7, 5, 3, 0, 9}, n) == 0) {}
  

• Designated initializers for arrays are valid only in C:

  char s[20] = { [0] = 'a', [8] = 'g' };  // allowed in C, not in C++
  

• Functions that do not return can be annotated using a noreturn attribute in C++ whereas C uses a distinct keyword.

C++ adds numerous additional keywords to support its new features. This renders C code using those keywords for identifiers invalid in C++. For example:

struct template 
{
    int new;
    struct template* class;
};

is valid C code, but is rejected by a C++ compiler, since the keywords template, new and class are reserved.

Constructs that behave differently in C and C++

There are a few syntactic constructs that are valid in both C and C++ but produce different results in the two languages.

• Character literals such as 'a' are of type int in C and of type char in C++, which means that sizeof 'a' will generally give different results in the two languages: in C++, it will be 1, while in C it will be sizeof(int). As another consequence of this type difference, in C, 'a' will always be a signed expression, regardless of whether or not char is a signed or unsigned type, whereas for C++ this is compiler implementation specific.
• C++ assigns internal linkage to namespace-scoped const variables unless they are explicitly declared extern, unlike C in which extern is the default for all file-scoped entities. Note that in practice this does not lead to silent semantic changes between identical C and C++ code but instead will lead to a compile-time or linkage error.
• In C use of inline functions requires manually adding a prototype declaration of the function using the extern keyword in exactly one translation unit to ensure a non-inlined version is linked in, whereas C++ handles this automatically. In more detail, C distinguishes two kinds of definitions of inline functions: ordinary external definitions (where extern is explicitly used) and inline definitions. C++, on the other hand, provides only inline definitions for inline functions. In C, an inline definition is similar to an internal (i.e. static) one, in that it can coexist in the same program with one external definition and any number of internal and inline definitions of the same function in other translation units, all of which can differ. This is a separate consideration from the linkage of the function, but not an independent one. C compilers are afforded the discretion to choose between using inline and external definitions of the same function when both are visible. C++, however, requires that if a function with external linkage is declared inline in any translation unit then it must be so declared (and therefore also defined) in every translation unit where it is used, and that all the definitions of that function be identical, following the ODR. Note that static inline functions behave identically in C and C++.
• Both C99 and C++ have a boolean type bool with constants true and false, but they are defined differently. In C++, bool is a built-in type and a reserved keyword. In C99, a new keyword, _Bool, is introduced as the new boolean type. The header stdbool.h provides macros bool, true and false that are defined as _Bool, 1 and 0, respectively. Therefore, true and false have type int in C.

Several of the other differences from the previous section can also be exploited to create code that compiles in both languages but behaves differently. For example, the following function will return different values in C and C++:

extern int T;

int size(void)
{
    struct T {  int i;  int j;  };
    
    return sizeof(T);
    /* C:   return sizeof(int)
     * C++: return sizeof(struct T)
     */
}

This is due to C requiring struct in front of structure tags (and so sizeof(T) refers to the variable), but C++ allowing it to be omitted (and so sizeof(T) refers to the implicit typedef). Beware that the outcome is different when the extern declaration is placed inside the function: then the presence of an identifier with same name in the function scope inhibits the implicit typedef to take effect for C++, and the outcome for C and C++ would be the same. Observe also that the ambiguity in the example above is due to the use of the parenthesis with the sizeof operator. Using sizeof T would expect T to be an expression and not a type, and thus the example would not compile with C++.

Linking C and C++ code

While C and C++ maintain a large degree of source compatibility, the object files their respective compilers produce can have important differences that manifest themselves when intermixing C and C++ code. Notably:

• C compilers do not name mangle symbols in the way that C++ compilers do.
• Depending on the compiler and architecture, it also may be the case that calling conventions differ between the two languages.

For these reasons, for C++ code to call a C function foo(), the C++ code must prototype foo() with extern "C". Likewise, for C code to call a C++ function bar(), the C++ code for bar() must be declared with extern "C".

A common practice for header files to maintain both C and C++ compatibility is to make its declaration be extern "C" for the scope of the header:

/* Header file foo.h */
#ifdef __cplusplus /* If this is a C++ compiler, use C linkage */
extern "C" {
#endif

/* These functions get C linkage */
void foo();
 
struct bar { /* ... */ };

#ifdef __cplusplus /* If this is a C++ compiler, end C linkage */
}
#endif

Differences between C and C++ linkage and calling conventions can also have subtle implications for code that uses function pointers. Some compilers will produce non-working code if a function pointer declared extern "C" points to a C++ function that is not declared extern "C".

For example, the following code:

void my_function();
extern "C" void foo(void (*fn_ptr)(void));

void bar()
{
   foo(my_function);
}

Using Sun Microsystems' C++ compiler, this produces the following warning:

 $ CC -c test.cc
 "test.cc", line 6: Warning (Anachronism): Formal argument fn_ptr of type
 extern "C" void(*)() in call to foo(extern "C" void(*)()) is being passed
 void(*)().

This is because my_function() is not declared with C linkage and calling conventions, but is being passed to the C function foo().

External links

• Detailed comparison, sentence by sentence, from a C89 Standard perspective.
• Incompatibilities Between ISO C and ISO C++, David R. Tribble (August 2001).
• Oracle (Sun Microsystems) C++ Migration Guide, section 3.11, Oracle/Sun compiler docs on linkage scope.
• Oracle: Mixing C and C++ Code in the Same Program, overview by Steve Clamage (ANSI C++ Committee chair).