- 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
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
/* … */ and
// … comments while C only supports the
/* … */ style.
is neither right nor wrong.
- 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.
- 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.
- 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.
- 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.