No it is not.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Many equate "C == what my compiler does", but just like any standardized technology with holes open to implementers to decide upon, portability isn't as people think.

I read Chris Lattner's posts. There are definitely things the standards don't specify that people take for granted (twos-complement for example). C is still an order of magnitude easier to parse than C++ though (especially modern). In theory, implementing and maintaining a compiler for it for a platform should be simpler.

Implementing an effective compiler is another concern entirely, but I would still argue that there tend to be more incompatibilities between C++ implementations than C.

Yes, parsing is way harder because C++ requires the context aware grammar.

However many C++ incompatibilities are actually caused by C compatibility and the goal of having higher constructs that are copy paste compatible with C but with additional semantics, e.g. structs.

So in both cases, to achieve your portability goal the languages would have to be fully specified.

C and C++ are admittedly different languages, but I would think more than less of the code for compiling both languages should be the same. I personally can't see how one language would impede the other.

As a C/C++ user, I'm honestly still not sure why a number of C features have yet to be formalized in C++ (e.g. restrict).