Projects for Apple platforms usually also use .h, where it could mean anything from C/C++ to Objective-C/C++.
In practice, Clang handles mixed C/C++/Obj-C codebases pretty well and determining the language for a header never really felt like an issue since the API would usually already imply it (declaring a C++ class and/or Obj-C class would require the corresponding language to consume it).
If a C++ header is intended to be consumed from C, adding the usual #ifdef __cplusplus extern "C" {... should alleviate the name mangling issues.
Yeah, I was ignoring apple platforms because Objective-C doesn’t even have its own header extension as an option. Also not all C headers do extern stuff…and it doesn’t fix 100% of compatibility problems when you do that anyway. Also I’m not really talking about it from a compiler perspective, I’m talking about it from an organization and human perspective. I know compilers generally don’t care…which is exactly how we ended up in this predicament.
Projects for Apple platforms usually also use .h, where it could mean anything from C/C++ to Objective-C/C++.
In practice, Clang handles mixed C/C++/Obj-C codebases pretty well and determining the language for a header never really felt like an issue since the API would usually already imply it (declaring a C++ class and/or Obj-C class would require the corresponding language to consume it).
If a C++ header is intended to be consumed from C, adding the usual
#ifdef __cplusplus extern "C" {...should alleviate the name mangling issues.Yeah, I was ignoring apple platforms because Objective-C doesn’t even have its own header extension as an option. Also not all C headers do extern stuff…and it doesn’t fix 100% of compatibility problems when you do that anyway. Also I’m not really talking about it from a compiler perspective, I’m talking about it from an organization and human perspective. I know compilers generally don’t care…which is exactly how we ended up in this predicament.