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++95 is a workable language, the usable superset of later versions of C with later versions of C++95 has probably shrunk rather than grown (thanks to things like the Strict Aliasing Rule) and trends favor an ever-increasing fissure.

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.