If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C.
The Lua interpreter is written in a subset of C so that it also compiles fine as C++. Or, if you prefer, in a subset of C++ so that it compiles fine as C.
Requiring explicit casts, and forbidding implicit conversions, reduces the odds of being surprised by an unwanted conversion. There's a good argument to be made for adding explicit casts to C code even when the language doesn't require them. GCC's -Wconversion flag can help with this.
Yes.
> That isn't a significant burden.
But once you do it your "C" code is littered with a lot of unnecessary casts that increase the verbosity of the code and could hide errors. With pre C99 code it would also hide default int errors if the include for malloc gets lost at some point.
How? As I said, the stricter rules of C++ result in fewer type-conversion errors than C's permissive rules. That's the reason for C++'s stricter rules, and it's the reason Ada is even stricter.
As an example, consider
a = b = c;
b = c;
a = c;
> With pre C99 code it would also hide default int errors if the include for malloc gets lost at some point.
Wouldn't it just fail to compile if you're missing a required header?
edit steveklabnik linked to [0] so I see what you mean now. I think that's a valid point.
There's also no ambiguity. You've already explicitly defined the variable's type at that point.
There is harm in implicit conversions catching the programmer unawares. This is a fairly significant cause of bugs in C code, and it's why C++ uses stricter rules, requiring you to always make these conversions explicit, even when using malloc.
I would also argue that there's a hard to quantify harm in making code more verbose. More visual noise makes it harder to parse what's going on. Sure, one redundant cast isn't going to kill you. But many sources of repetition across an entire code base eventually turn it into a slog where the parts you want are obscured by useless noise.
Simplest example is that a `void func()` decl in C and C++ have different semantic meanings.
You can also tell that the C++ standard committee agrees with this to some extent since they tend to add C novelties into the C++ standards whenever possible to make it easier to write compatible code, for instance: https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibi...
It's a bit like saying that operating the windscreen wipers is a subset of knowing how to drive a car. It's strictly correct, but it's probably not where you should start nor where you should put most of your attention if you're looking to get you license.
What's happened is the direct opposite of C++ where every fad gets added to the language. With C lots of standard proven features don't make it into the language.
It is easy to write C code that is compatible with C++ if you have compatibility in mind from the beginning. Most of time: 1) cast malloc() – you can define macros for less code; 2) avoid C++ keywords; 3) don't use VLA which is not recommended anyway; 4) add __STDC_LIMIT_MACROS for uint64_t etc. Use -Wc++-compat also helps. It is harder to modify existing C code for the compatibility with C++.
Surely you need to modify C code to compile it with C++ and in the article we made an example of the modification. But the point is that the changes are pretty straightforward and small.
And yet the standard practice for games written in C attempting to use Valve's C++ API for Steamworks integration is to switch to using a C++ compiler.
[1] https://github.com/nospaceships/raw-socket-sniffer/blob/mast...
[2] https://github.com/GirkovArpa/raw-socket-sniffer/blob/master...
Even then, I never use the latest standards of C++, I stay a couple standards behind so I can rely on whatever compiler I pick being able to handle it. Right now I'm using C++14.