Well i don’t really have a choice as i want to code some stuff for my smartwatch (pine time) and also wanted to take a look at the code of the hyprland window manager (wich is written in C++ afaik)
Ah…well fair enough. I personally prefer plain C but I know nothing about the pine time or what languages are available and even then Hypr and Hyprland are C++ so you are trapped there…sway ftw lol. Also my pedantic side dictates I must say this even though it’s irrelevant…but technically Hyprland is a Wayland compositor and while they do manage windows a window manager is an X term…
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.
Yeah. My original comment should have been “I wish people would use a C++ specific extension for headers.” I just picked hpp because cpp seems to be the most widely used C++ extension.
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.
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.
I don’t code in C++ (although I’m somewhat familiar with the syntax). My understanding is the header files should only contain prototypes / signatures, not actual implementations. But that doesn’t seem to be the case here. Have I misunderstood, or is that part of the joke?
Not a C++ developer, I prefer C. You are right in general however my understanding is that classes which are generic using templates must be fully implemented in header files because of how templates are implemented. That being said this code doesn’t appear to use templates so I’m not entirely sure I get it either?
Well, it’s even just horrid code, because they’re reading user input in some random associated function, so I think, it’s safe to say that this is supposed to be horrid code.
I’m not fully sure what the intent of the joke is, but note that yes, it’s true that a header typically just has the prototype. However, tons of more advanced libraries are “header-only”. Everything is in a single header originally, in development, or it’s a collection of headers (that optionally gets “amalgamated” as a single header). This is sometimes done intentionally to simplify integration of the library (“just copy this files to your repo, or add it as a submodule”), but sometimes it’s entirely necessary because the code is just template code that needs to be in a header.
C++ 20 adds modules, and the situation is a bit more involved, but I’m not confident enough of elaborating on this. :) Compile times are much better, but it’s something that the build system and the compilers needs to support.
Do other languages separate definition from implementation? 🤔 Is there another way to distribute libraries with a binary component and a public component?
Anyway, you don’t need to separate them in your source code to have a legible component on your distributable. C is the only language that insists you must have part of the source code before you can use the very public perfectly clear interface that is written all over shared libraries.
Also, you can distribute proprietary libraries by source perfectly well. And it’s the standard except on very few cases where a corporation can coerce most of the world on accepting any shit.
Add comment