I really wish more projects would use .hpp to differentiate from C headers. It’s really annoying to have a single header extension blend across two incompatible languages.
It’s actually not. Objective-C is a superset of C. C++ is not. It’s MOSTLY compatible…but it’s not a superset. See the restrict keyword, or the need for casting to and from void*, or the inability to name variables new or delete, or class, or this. I can’t count how many C projects I have which use this as a variable name that WILL NOT compile as C++…or the need for extern C to call C ABI code…in no way is it a superset
EDIT: lol, you can downvote me if you want but I think you need to lookup what a superset is
I did this in a project and someone later came and changed them all to .h, because that was “the convention” and because “any C is valid C++”. Obviously neither of those things is true and I am constantly befuddled by people’s use of the word convention to mean “something some people do”. It didn’t seem worth the argument though.
…so that leads to another annoyance of mine. The insistence that there aren’t two languages but indeed one named C/C++. Obviously I’m being a bit sarcastic but people blur the lines HEAVILY and it drives me crazy. Most of the C code I’ve written is not compatible with C++…at least not without a lot of type casting at a bare minimum. Or a compiler flag to disable that. Never mind the other differences. And then there’s the restrict keyword, and the ABI problems if the C library you’re using doesn’t extern C in the headers…etc etc… -_-
Yeah, I use that all the time. I think I use it in a different way though. I have projects with C, C++ and other languages. The C and C++ get compiled and linked together, and so there are some considerations for those files that don’t apply to anything else. So I mean C files and C++ files, but not as if they were the same language.
Yeah that’s completely fair and makes sense to me. I just know I’ve come across stuff where people are talking about it like they’re the same language. This seems to be especially prevalent in windows development where the C support is pretty poor in comparison and tends to kinda be lumped into into C++.
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.
I really wish more projects would use .hpp to differentiate from C headers. It’s really annoying to have a single header extension blend across two incompatible languages.
C++ is a superset of C.
hpp is a superset of h
It’s actually not. Objective-C is a superset of C. C++ is not. It’s MOSTLY compatible…but it’s not a superset. See the restrict keyword, or the need for casting to and from void*, or the inability to name variables new or delete, or class, or this. I can’t count how many C projects I have which use this as a variable name that WILL NOT compile as C++…or the need for extern C to call C ABI code…in no way is it a superset
EDIT: lol, you can downvote me if you want but I think you need to lookup what a superset is
I did this in a project and someone later came and changed them all to .h, because that was “the convention” and because “any C is valid C++”. Obviously neither of those things is true and I am constantly befuddled by people’s use of the word convention to mean “something some people do”. It didn’t seem worth the argument though.
…so that leads to another annoyance of mine. The insistence that there aren’t two languages but indeed one named C/C++. Obviously I’m being a bit sarcastic but people blur the lines HEAVILY and it drives me crazy. Most of the C code I’ve written is not compatible with C++…at least not without a lot of type casting at a bare minimum. Or a compiler flag to disable that. Never mind the other differences. And then there’s the restrict keyword, and the ABI problems if the C library you’re using doesn’t extern C in the headers…etc etc… -_-
Yeah, I use that all the time. I think I use it in a different way though. I have projects with C, C++ and other languages. The C and C++ get compiled and linked together, and so there are some considerations for those files that don’t apply to anything else. So I mean C files and C++ files, but not as if they were the same language.
Yeah that’s completely fair and makes sense to me. I just know I’ve come across stuff where people are talking about it like they’re the same language. This seems to be especially prevalent in windows development where the C support is pretty poor in comparison and tends to kinda be lumped into into C++.
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.