Please, C and C++ share a large subset, and, most importantly a memory model. Java and JS share, what, a couple of parentheses?
What they don't share is mindset; C is all about keeping it simple, I don't even know what C++ is about any more, but it sure isn't simple. Many fundamental tricks that are routinely pulled in C require jumping through plenty of hoops to keep a modern C++ compiler happy.
Speaking of interop, calling into C from other languages is very different from calling into C++. Yes, you can write C wrappers, but it's rarely done. And the further the language drifts into template lala land, the more tricky it gets.
Not in my experience. Currently my man open source project consists of some 70,000 of C which compiles as C++. Maintaining C++ compatibility takes very little effort. I tend to switch to C++ before a release, to catch regressions. Often there is nothing. The most I spend is maybe five to ten minutes fixing some minor things. Some of those minor things have nothing to do with C versus C++ like signed/unsigned warnings.
Note that these signed/unsigned warnings from GNU C++ actually found a real problem: I had code which assumed WEOF was negative. (It was originally char based code that was switched to wchar_t; of course EOF constant in the narrow character world is negative.) The GNU C++ compiler also identified the situation in the same code that a variable that should have been wint_t was mistakenly int.
The classic struct hack looks like:
struct header {
size_t size;
char data[1]; // not [0]
};
Automatic void casts are a misfeature in both languages; more so in C. In code that I control, I use a pointer to a character type as an "any memory" type, so that it requires a cast in both directions:
E.g.
typedef unsigned char mem_t;
I use macros for casts, which compile to the classic C cast in C, and the more restricted casts in C++:
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif
The stupid void star thing and its conversion rules should never have been invented. C++'s treatment of it is more sane, at least, by working without a cast in only one direction.
What's really awful is official API's that use void star for opaque handles. The Kronos Group's OpenMax is one of these. You can mix up different kinds of handles for different objects and the calls will compile.
That's like your opinion, plenty of C programmers worth their salt would disagree with you.
Look, I'm not saying it's impossible to write code that compiles both as C and C++. The same is true of many other languages. The point is that you can't write C and expect it to be valid C++, which was the only thing I claimed.
Then my project grows to the point where I need to do some simple string operations.
At which point I remember the wonderful simplicity of garbage collected, high level languages...
A modern C++ compiler will have all sorts of issues with fundamental C idioms, and depending on C++ is a very different story from depending on C.
I maintain a significant body of code which compiles as C or C++. The executable size and performance are about the same.
A C++ compiler will, of course, have "issues" with C99 and C11 features, that's for sure.
Here let me note that I have not gone out of the way to disable anything in C++. I have not disabled EH in the compiler, or RTTI or anything. Yet, the executable size is close to the C one, and the performance is basically the same.
well, did you know that for instance the windows C library was implemented in C++ ? and yet we don't see it throwing exceptions left and right.