Should I stop using the term C/C++?

Question

I understand C and C++ are different languages but when I was learning C++ I was always told that C is a subset of C++ or C++ is C with classes. And that was quite true until the appearance of C++x0, C++11 (or the modern C++ 11/14/17 in general). In fact (especially when working on embedded systems) it's very likely to find code written in C++ but with a lot of parts written entirely in pure C language. Here I have several questions:

1. Should I stop using the term C/C++?
2. If the answer to #1 is yes, how would I call a program that use a mix of C and C++?
3. Given that both of them are 'different' languages is it likely that at some point C++ compilers stop supporting code written in the C language (since modern c++ is diverging from the C mentality for basic stuff like pointers, dynamic memory handling, etc)
4. Is there right now any collaboration between the people who makes the standards of C/C++ to keep the compatibility
5. If #4 is yes, such collaboration could end up in the near future with the appearance of the modern c++ (11/14/17)

I know that there already similar questions, but I'm sure that a lot of people share these questions so I'm very interested to get good answers especially for the points that have to do with the C++ tendency in the near future.

Answer 1

C was never a subset of C++. The most obvious example of this is int new;. This has been true since C89 and C++98, and the languages have only grown further from each other as new standards have come out.

Should I stop using the term C/C++

Yes

If the answer to #1 is yes, how would I call a program that use a mix of C and C++?

A source file is written in one language or the other. A program can consist of code from multiple languages working together, or an executable produced by linking different compiled objects. You would say the program was written in C and C++, "C/C++" is not a language.

Given that both of them are 'different' languages is it likely that at some point C++ compilers stop supporting code written in the C language

3. They never did. char *a = malloc(10);. C and C++ have never been fully compatible for at least as long as they've had ISO standards (I don't know all the details about the pre-standardized days). click the links or see below for a file that is fine with C89 and up, but isn't valid under any C++ standard.

4. afaik no, but I don't know much about the C working group.

/* A bunch of code that compiles and runs under C89 but fails under any C++ */

/* type aliases and struct names occupy separate namespaces in C, not in C++ */
struct S { int i; };
typedef int S;


struct Outer { struct Inner { int i; } in; };
/* struct Inner will be Outer::Inner in C++ due to name scope */
struct Inner inner;


/* default return type of int in C, C++ functions need explicit return types */
g() {
    return 0;
}


/* C sees this as two declarations of the same integer,
 * C++ sees it as redefinition */
int n;
int n;


/* K&R style argument type declarations */
void h(i) int i; { }


/* struct type declaration in return type */
struct S2{int a;} j(void) { struct S2 s = {1}; return s; }


/* struct type declaration in argument, stupid and useless, but valid */
/*void dumb(struct S3{int a;} s) { } */


/* enum/int assignment */
enum E{A, B};
enum E e = 1;


void k() {
    goto label; /* C allows jumping past an initialization */
    {
        int x = 0;
label:
        x = 1;
    }
}


/* () in declaration means unspecified number of arguments in C, the definition
 * can take any number of arguments,
 * but means the same as (void) in C++  (definition below main) */
void f();

int main(void) {
    f(1); /* doesn't match declaration in C++ */
    {
        /* new is a keyword in C++ */
        int new = 0;
    }

    /* no stdio.h include results in implicit definiton in C.  However,
     * as long as a matching function is found at link-time, it's fine.
     * C++ requires a declaration for all called functions */
    puts("C is not C++");
    {
        int *ip;
        void *vp = 0;
        ip = vp; /* cast required in C++, not in C */
    }
    return 0;
}

/* matches declaration in C, not in C++ */
void f(int i) { }

I always feel it's worth mentioning that C is a subset of Objective-C.

Answer 2

There has to be a reason why these terms come together so often. While you should not tell your C teacher that his language is a subset of C++, there is some truth here. Others already have exposed your teacher's point of view. This is very nice (and illustrated with examples, etc.). But we don't live in an ivory tower, or a book.

Your big boss could not care less about the exact language you used. If he knows a bit about programming, just tell him you used C/C++ and it will sound like "I used a language that needs to be compiled to machine code, with DLLs and all the complicated stuff". This is the "external communication" part.

If you create a library that can be interfaced by both C and C++, you definitely want to call it a C/C++ library. Of course, someone will raise a hand and ask why you don't call this a C library that happens to have a C++ wrapper, and anyway C++ can link to C libraries so you don't need to mention it at all. Just answer: "Yes, you are right, this is a C/C++ library". This is the "internal communication" part.

If you create a lexical analyzer for C++, you'd be surprised how well it works with C. You might even not need to modify it all. This is the "if it looks like a duck, etc." part.

Etc.

The majority of C programs I have ever seen compile (and work) without modification as C++ code. Don't let a few exceptions or dogmatic (however influential) programmers fool your intuition. C and C++ are so close, and so often compatible, and so often mixed and matched together, that the term C/C++ is used. It is used because it is useful to describe these kinds of situations where it does not really matter whether you are considering C or C++, as long as it's not Java or PHP. We know it's "wrong", but we don't care, it's more useful than wrong.

It may be abused, it may be stupid, but still, I'm not sure what benefit you will get by being more pedantic than needed and refuse to communicate in terms that others understand. If you feel uneasy in some specific situation, then simply don't use the generic term C/C++, but the one relevant to the case (either C or C++).

Don't be afraid of the future. Our operating systems are written in C. Quite a lot of the C/C++ current software production happens in C++. This couple is here to stay for quite a while. Nobody has interest in one being made more incompatible with the other (quite the other way around, actually).

To be specific about your points:

1) It depends. Yes when it could lead to a confusion, when you feel uneasy, or when it's simply wrong or out of context. No when you think it's adequate.

2) N/A

3) I think no, but I have no crystal ball.

4) no idea

5) I don't think so as nothing pushes in this direction

Answer 3

Going against the flow I would say it depends on the context.

The term "C/C++" is usually not appropriate when saying something like "this is a C/C++ program", but this has been explored to depth in other answers.

However, there might be contexts where C/C++ can be appropriate.

• There are various libraries which usually have both a C and a C++ API. I guess it's not far from the truth if you call such a thing a C/C++ library. We humans like to compress information, so saying "opencv is a C/C++ library" is short, clear, and understandable, compare it to saying "opencv is a library, which is shipped with headers both for C and C++".
• You can talk about language design and syntax. From the point of view of the language syntax, you might say that a language has C/C++ -like syntax.
• You organize a coding contest, and you accept both solutions written in C and in C++
• You are hiring a new programmer, and most of the tasks will be either C or C++, so the programmer is expected to know both languages. It's common in embedded development, where C is more suitable for some (usually very small) microcontrollers, and C++ for others. In this case you might say you are looking for a C/C++ programmer.

Answer 4

In general the SO users ask the person who is asking the question to choose a language: C or C++. Why?

There are many subtle differences between C and C++. For example, in C++, a const variable at global scope has internal linkage unless declared extern, but in C it has external linkage unless declared static. By saying "C/C++", the OP is asserting knowledge that the answer to their question is the same in both C and C++, when it very well might not be. This needlessly makes things harder for would-be answerers.

• Sometimes we can spot that the code isn't valid in one language or the other (for example, implicit conversions from void* to pointer to object are not valid in C++). This is annoying. Why are you saying "C/C++" when you have a piece of code that's valid in C but not C++? Did you intend C, or is this just an error in code intended to be C++?

• Sometimes the answer will be different depending on the language (for example, variable-length arrays exist in C99 but not in C++). If we don't know what language you're talking about, either we have to guess, or write an answer for both when only one will actually be useful, because you know which language you're actually using; you're just not telling us!

• Sometimes the answer really is the same for both languages, but it's hard to be sure. For example, I think C and C++ have the same integer conversion rules, but in order to be really, really sure, I have to read both standards carefully. Again, this makes me do twice as much work as necessary when you probably only care about one of the languages.

Anyway, to answer your other questions:

1. Yes.

2. If you are linking together C and C++ code, it is acceptable to use both tags, but please specify which language each file is in.

3. There are breaking changes sometimes, but they're rare and typically limited in impact (otherwise they don't get approved). For example, auto in C++11.

4. I don't think they directly collaborate, but they pay attention to developments in the other language and try to avoid introducing changes that would make compatibility more difficult.

And if you really do want to know about both languages, that's fine, and you can say that in your question. When you say "C/C++", I'm really not sure what you mean, and it really looks like you're making an assumption about the two languages.

Answer 5

I was always told that C is a subset of C++ or C++ is C with classes. And that was quiet true until the appearance of C++x0, C++11 (or the modern C++ 11/14/17 in general).

C has never been a subset of C++. For example C89 is not a subset of C++98.

A few examples:

• the C89 identifier-list form for function parameter declaration is not supported in C++
• C89 and C++98 have different types for the characters constants
• C89 and C++98 have different types for string literals
• logical operators yield different types in C89 and C++98 (int vs bool)

1. Should I stop using the term C/C++?

Yes.

2. If the answer to #1 is yes, how would I call a program that use a mix of C and C++?

A program is either C or C++ (if even some very basic program can compiled with either a C or a C++ compiler). What compiler are you using to compile it? It should answer your question. Harbison & Steele coined the term Clean C to designate a common subset of C and C++ but I think it was a bad idea.

EDIT: However I admit that technically you can link C and C++ objects files in a single program but OTH there are many languages that are allowed to be mixed in a single program for example Java and C++. I think using the term C/C++ program only adds to the confusion that it is written in a single language called C/C++.

3. Given that both of them are 'different' languages is it likely that at some point C++ compilers stop supporting code written in the C language (since modern c++ is diverging from the C mentality for basic stuff like pointers, dynamic memory handling, etc)

There are many features (example: variable length array, flexible array member, _Generic, ...) of C99 or C11 that are not supported by any C++ version.

Answer 6

Some programs are written in a mixture of C and C++

This is just a fact of life. You can compile object files from C and C++ and link them together. The result can quite reasonably be called "a C/C++ program".

But that's only the program as a whole. What about the individual compilation units?

There is a subset of C which is also a subset of C++

A program (or compilation unit) written in that subset will compile and behave the same under conformant C and C++ compilers. Such a program or file can rightly be called "a C/C++ program" or "a C/C++ file".

A partial program such as a header file may also be used in both C and C++ programs. Such header files can rightly be referred to as C/C++ headers.

Quoting Professor Bjarne Stroustrup:

Is C a subset of C++?

In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++. However, C++ supports every programming technique supported by C. Every C program can be written in essentially the same way in C++ with the same run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program.

• http://www.stroustrup.com/bs_faq.html#C-is-subset

So yes there is such a thing as C/C++. It's anything which is both valid C and valid C++.

The C pre-processor is part of the C language. The C++ pre-processor is part of the C++ language

You can write a compilation unit which will compile under C or C++ and be different. For example, it might have basic functionality compiled in C but take advantage of a C++ library if compiled in C++.

If the program is essentially the same, but with additional features, it's not exactly wrong to say it's the same program. Its the same, but also different.

Most C programmers can do at least a little C++ and vice-versa

It's not unreasonable to call such a person a C/C++ programmer. Yes, they probably specialise in one, but is there anyone who is a competent C or C++ programmer who literally cannot do any of the other language? In a way, aren't they all C/C++ programmers?

There's nothing wrong with saying "C/C++". What matters is being understood

The English language is not a tool for expressing syllogisms. You can use English for logic, but only just, and with great effort.

This is because words do not naturally have exact meanings, but rather a vague cloud of denotations and connotations. What matters is if people understand what you are saying.

Answer 7

1. Should I stop using the term C/C++?

Absolutely. It is not clear what this construct is intended to express except, perhaps, confusion about what C and C++ are on behalf of the person who uses the term.

Since this confusion is such a common source of frustration, many people have become quite emotional about it and appearance of that term alone will be reason enough for them to become negative about your contribution. This might seem silly but it appears to be what we have.

I recommend that instead of talking about “C/C++” you use a term that actually makes clear what you mean.

• If you are talking about something in C that might or might not also be true for C++, simply say C.

  Example: How should the main function be declared in C?

  At first, it might seem that the answer for C++ is the same: int main() or int main(int, char**). But as the discussion goes on, it might be relevant to point out that in C++, the function has to be declared at global scope, which doesn't make sense in C, because it has no namespaces. On the other hand, C allows calling main recursively while C++ doesn't. In C++, there is an implicit return 0; if you “fall off” main but in C the return statement is required on any path. The list goes on and it makes the discussion much simpler if you make it clear up front what the language to be discussed is.

• If you are talking about something in C++ that might or might not also be true for C, simply say C++.

  Example: Will a malloc()ed array of ints initially be all-zeros in C++?

  The short answer for C happens to be the same: no. But as the answer goes on, it might be worthwhile to point out that in C, calloc would be a good alternative while in C++, using a std::vector<int> might have been a better choice in the first place.

• If you want to point out a similarity between C and C++, say C and C++.

  Example: In C and C++, the sizeof an int is implementation defined and may vary between compilers and architectures.

  Here, we want to point out that C and C++ behave the same way. We are explicitly talking about both languages.

I actually recommend that you be even more specific and not only talk about “C” or “C++” but the precise version. Both languages are evolving and a blunt statement such as

C++ supports /* … */ and // … comments while C only supports the /* … */ style.

is neither right nor wrong.

2. If the answer to #1 is yes, how would I call a program that use a mix of C and C++?

Since the languages have overlap, every C program will contain parts that might look like C++ and vice versa. Nevertheless, the authors will probably have settled onto using either a C or a C++ compiler. So say “the program is written in C” if it is compiled with a C compiler and “the program is written in C++” if they use a C++ compiler, even if they might refuse to use any modern C++ features. Some people refer to such C++ code as C-style C++. Absence of overloading, exceptions, polymorphism, templates and I/O streams a common characteristics of such code.

If, instead, some files are written in C and compiled with a C compiler and some other files are written in C++ and compiled with a C++ compiler, and then the object files linked together, I would say that “the program is written in a mix of C and C++” as, in fact, you already did.

However, if, instead, the authors took great care to write each and every file in such a way that it can be compiled with a C or a C++ compiler and the resulting program would do the same thing, you could say that “the program is written in a common subset of C and C++”.

The latter is often the case for header files that should be shared between C and C++ code. Writing such code is not easy, by the way. If you want to further emphasize that only such constructs were used that are valid in C and C++ and are widely supported by different compiler vendors, the term a portable common subset of C and C++ may be used to emphasize this.

3. Given that both of them are “different” languages is it likely that at some point C++ compilers stop supporting code written in the C language (since modern C++ is diverging from the C mentality for basic stuff like pointers, dynamic memory handling, etc)?

I'm not sure I understand this question. Since C and C++ are different languages, you cannot expect a compiler for one of them accept a program written for the other. However, compilers are often designed in a modular way and if a compiler has a C++ front-end, chances are good it will also have a C front-end. (You would then select which of them you want via a command line switch or similar means.) As long as both languages will be in widespread use, it seems very unlikely that this is going to change. Your point about “modern C++” I think is basically a matter of good coding standards and the standard library. From the compiler's point of view, the evolution of both languages is rather converging than diverging.

4. Is there right now any collaboration between the people who make the standards of C/C++ to keep the compatibility?

Yes. The memory model and the atomic operations library introduced in C++11 and C11 is a good example. It seems that the designers of both languages realize that compatibility is important and are working towards improving it. Personally, I'd wish that the collaboration were more intense and the two ISO working groups perhaps even joined but my wishes are not important.

Bjarne Stroustrup talks about the differences and commonalities between the various versions of C and C++ in § 44.3 of the 4th edition of The C++ Programming Language which, ironically, is titled “C/C++ Compatibility”. Use of the term might actually be appropriate in this case as it is clear what is meant.

5. If #4 is yes, such collaboration could end up in the near future with the appearance of the modern C++ (11/14/17)

As discussed above, it happened in C++11 and is expected / hoped / needed to happen again.

Answer 8

C/C++ is the intersection of C and C++.

int new; is not C/C++, and neither is vector<int> foo;.

Similarly, C89/C99 is the intersection of these two languages, where neither enum bool { false, true }; or for(int i = 0;;) is allowed.

And C++11/C++14, etc.

It is possible to write code that compiles (and correctly runs) under C++11 and C++14, even though compiling under one doesn't imply it compiles under the other. In fact, a lot people do this.

And a lot of people write code that works in C and C++.

Obviously, the greater the overlap, the more sense it makes; I don't expect to see any questions about C/C++/Java code.

---

Though it does "make sense" to talk about a common subset of these languages, many questions will not have answers in this subset, e.g. What should main() return in C and C++?

But you can talk about code that works for multiple language specifications, whether those specs are differentiated by "version" or "language name" or otherwise.

Answer 9

This is a response of sorts to the position that "this is a code for programmers who work close to the metal and is OK in a management context" seen in some of the other answer and comments.

---

I'd argue that even that interpretation should be taken with care.

Starting by at least the mid '90s if you wanted a C++ programmer and someone who described themselves as a C programmer applied you'd have had to ask how much they know about object oriented design, how much experience they have with debugging in an object oriented context, and about their ability to use template libraries. You'd want to probe exactly those issues during the interview and hiring process.

On the flip side, it has now been more than a decade since C++ gurus started pushing "modern C++" meaning a emphasis on moving away from bare pointers to safer pointer objects and iterator-based idioms. With the emergence of C++11 there is now explicit support for multi-paradigm programming and the push toward code that exhibits no bare pointers is very strong. What that means is that if I interviewed a C++ programmer for a C position today I'd be very concerned about checking how familiar this person was with actual, foot-shooting-enabled pointers.

I'm not in the business these days (even to the degree that I was when Stack Overflow was in its infancy), so I won't venture a guess at how often either imaginary interviewee would not have the cross-over skills, but I think that as most often applied the languages are now very different indeed.

In short "C/C++" should be dropped not only in technical contexts but in most business contexts as well.

Answer 10

The most simple answer to this question is that you should never have used that term. It is a term that should not exist. It has no meaning. Every program is either C, or C++.

And that was quiet true until the appearance of C++x0, C++11 (or the modern C++ 11/14/17 in general).

C++98 and 03 aren't even remotely C with Classes either. Whoever taught you this doesn't know shit and you can forget them. This was never correct.

Answer 11

Conceptually, there should be no particular difficulty with designing C source files so they they can also be compiled as-is with C++. There can indeed be some significant advantages to doing this. For example, when writing code for an embedded system it is sometimes helpful to be able to test the code on a hosted PC environment. If the code compiles cleanly as C++, it's possible to have a statement like "MOTOR_ENABLE = 1;" write to a volatile I/O bit on the embedded system (compiled as C), but trigger emulation logic on the PC (compiling as C++). It would also probably be possible to design a C++ type on the PC which would behave the way a uint16_t behaves on smaller embedded systems (so that e.g. given u16 x=65533;, a compiler would have to regard the value of x*x as nine, rather than having free reign to do anything it wants), though as yet none of my emulators have included that [in part because the C++ compilers I've used haven't done anything wacky in such cases].

Unfortunately, C programmers and C++ programmers have sufficient antipathy toward each other that the languages have, over the years, evolved in compatible ways. While C89 attempted to adapt some of the more useful features of C++ (such as function prototypes) an attitude seems to have emerged that programmers who want any of the features of C++ should use C++, ignoring the fact that there are many situations where it would be helpful to be able to use some of the features of C++ (e.g. the ability to overload functions with static or static inline linkage without having to accept the costs associated with other features that one doesn't need (e.g. the name mangling associated with exporting overloaded functions).

While the intersection of C89 and C++98 is a workable language, the usable superset of later versions of C with later versions of C++ has probably shrunk rather than grown (thanks to things like the Strict Aliasing Rule) and trends favor an ever-increasing fissure.