Thank’s for those tips i’m learning programming with c++ as first language and this is really helpful thank’s 😊

I've been writing C++ code since the early 90s. I have never had an issue with the fact a file is named .h. Yeah, sometimes a file is intended for C or C++ exclusively, but that doesn't cause hours of confusion. Personally, I prefer the use of .h and, if necessary, introduce 'extern "C"' or whatever as necessary.

The problem I have with using ".hpp" for every c++ header is that by convention of the libraries I've seen, ".hpp" is usually reserved for templated headers or headers that contain the full implementation of the class/functions without a corresponding ".cpp" file at all, which is not something you want to automatically imply for every header in your project. And the other options ".hh", "h++", etc, just aren't that common and look weird to me.

We could follow the fantastic example of the C++ standard library and just not put extensions at all, just like <ranges> or <iostream>.

+1 for passion

I dont get it. Maybe with some practical examples, or it just a conceptual thing.

Stop telling people to use .hpp for C++ header files. This is a recurring problem with inexperienced developers that goes all the way back to the 90's. It seems logical to ask, "well we use .c for C files and .cpp for C++ files, so why not .h and .hpp?"....... Well, the only people I have run into in the 30 years I have been a C++ coder that think this way are people who don't understand how the "extern C" construct works. C and C++ header files are the same. Modern C code is wrapped in an extern C block in the header file to tell the compiler that it is C code and not C++. I am SICK and TIRED of batch-renaming files and refactoring code to remove include statements that reference .hpp files when some inexperienced joker set it up that way.

I clicked the 776th like, I just wondering who got the 777th like ~ for the h vs hpp thing, I always feel like when I see hpp file, it will include template code for some reason, and reading those code will make my brain switch to high power consumption mode and that is not environment friendly.

Nope. If my compiler can figure out if the code in my .h header C++ files is C or C++ then the tooling should be able to as well.

Modernize this please 😊

".hh" is also bad because it is an easy typo. ".h++" requires use of the shift key in an awkward way, "+" is a special char in some corner cases, and generally has no advantage over ".hpp" I've also seen ".hxx" which is a sort of "trying to be too clever" quasi-visual attempt at ".h++" while being portable to systems that don't allow "+" in filenames. I don't see any advantage of ".hxx" over ".hpp"

Too much self promo

i always thought that if someone "invented" hpp extension for c++ headers then why not to use it :D

As an example that impacts me right now, I'm using raylib which is C and my program game is C++. So, yes, I'm dealing with mixed languages. I'll switch over myself to hpp. I don't feel strongly about it one way or the other. It just hasn't caused problems for me yet as a hobbyist, but it's nice to know.

I always used ".hpp" for template & inline definitions. Would ".hxx" for declarations and ".hpp" for definitions be acceptable or is there a reason to avoid this?

please, stop using vocal fry!

vscode actually assume .h are C++ which haven't caused me any problem with C, but is annoying by itself. In general it seems the languges need to get a divorce already, if even sharing header files is no longer a (positive) feature.

I've just done a check on a 20 million line project it has over 200,000 #include lines, 12,000 .h files to git mv, I'm prettier sure this would break the IDK and it would I break any integrations. I'm feeling like the moment for this suggestion was 30 years ago, I guess given that CFront was "C with Classes" you can understand why .h became prevalent with C++. It feels like a lot of flux for really very little gain, noble but a little futile. You normally say pretty sensible things, but I can't get behind you on this one.

Bro sounds like the ”ehm actually 🤓“ emoji

It's better to use .hpp17 .hpp20 .hpp26 for c++ to make assumption of c++ being used :)

C++ source files should all have the file extension .cpp -> #include<foo.cpp> /S

This advice is applicable in projects mixing C and C++ code and definitely has merit there. In projects that use C++, but not C, I don't see any real issue.

I have been exclusively using .hpp files for my C++ projects for a few years now. It is just more correct.

instead of .h++ just use .i directly

Takes too long to get to the point

This is all good till you realize that MSVC treats any file that is different from .h as a source file and includes it to the file list for a linker. This becomes especially painful if you use any automating building tool like cmake or premake5.

Having short file extensions in header files, like h rather than hpp, is useful for IDEs (Integrated Development Environments). In user interface, in places where it needs to show a list of files, shorter names doesn't stack up and don't take that extra space. Otherwise using the h extension for C code exclusively makes more sense.

I have always used .hh or .hpp. They are C++. The .h-suffix is C.

One thing I've seen .hpp used for is header-only libraries, where it's used to imply "there is no corresponding .cpp file". I wonder what your thoughts are on that.

Another pointless video with 0 value. Also 1.5 min of self promotion in 6 minute video, I guess business not going well. Unsubscribed

i thought we shouldn't have to write any header files anymore. 😂

Nope. C++ has replaced C. Nobody is using a mixtures of both. The logic you mention belongs in a museum.

Honestly I can't think of a single valid reason not to use .hpp, you are absolutely right that we should... but I have also never worked on a project professionally where that was the convention so I doubt I ever will use .hpp. That said if we were working on a public library where external people would use the code I would be strongly pushing to use .hpp since as you said it is clearer that it is C++ code that way, and anything public facing should be as clear as possible.

Usually I unsub and block those who posts videos calling me to stop doing something, but I'll make one and only exception for you. Not going to watch this video anyway.

Header files are not compiled on their own. If a .h file is included in a .c file, it is compiled as C, in .cpp - as C++. I understand this might feel inelegant, but I have been writing C and C++ code for 28 years, and I don't recall ever being troubled by the ambiguity. 1:40 The Google C++ Style Guide recommends .h for C++. 2:20 Vim assumes .h files are C++. You might want to update your Bayesian priors, as well. :)

sorry, but this is BS of personal preferences. Similar to tab vs space.

I'm currently working on a project with .cxx and .hxx file extensions!

I've always just used *.cc and *.hh since those just make sense and are easy to type. Emacs tends to handle both just fine when I do that.

Library guys want to support C that's why their code is not readable

Thank you sir. You single handily convinced me on this!

Legit question: is there a shop that uses both C and C++ in a way that this would be an issue? This reminds me of a discussion I had decades ago with someone who was grumbling about MS Word trying (and failing) to open all his ascii text .doc files.

1:35 minutes advertisements for a 6 minutes video 😅

This does not worth any discussions. C++ being a big ball of mud of C burden who cares about having a header with .h or .hpp

Use .hpp instead of .h files

LOL nice bait, mate. I wish you hadn't said "pick whatever one you like" though. Ugh, chaos. Also, I think you might want to explain something: including headers that you don't know what the contents are? What on earth do you mean? You include headers that you don't know? I know you didn't mean that, haha.

While it certainly makes sense to explicitly use .hpp, the choice of .txt for CMake files bothers me much more.

I like a lot of what you talk about, but this is not great. You do not see an .h file and assume it is a c library. You know better. Maybe you see an .h and WANT to be able to assume this. If you assumed it .h was C you would not be effective. Even if you had .hpp as the extension, you need to know so much more to use the library or understand it. Knowing if it is C or C++ tells you almost nothing of value that doesn't come from more of the context that you must have. The file's status as a C or C++ file also has to do with how it is used and where it is included. "Your tools will assume it's C" Which tool? In what meaningful way? Given the fact that C++ code has been in .h files for years, the tool would be making the same bad assumption. If it can't function you have a tool problem, and given the choices the problem is on you as a dev. Telling the team to change so your antique editor can function is hardly compelling. Most of all: Even if I agreed, you cannot win. If you need it, you will not have it. You will lose, because others will not change. You are pushing against an infinite tide. If no one added a new .h cpp file from now on you would still be dealing with .h cpp files in decades. We had the chance to change decades ago. It would have been easy. It seemed like there might be a change, but it didn't happen. And we are OK. I will use either. If it makes a team happy, I use what they want. I think that's more important.

whatever happened to modules? is that something that didn't catch on and just acted to bloat c++ even more?

Gotta agree, we're long past the times when C++ was just C with classes, and C devs really struggle with .h files that are actually C++ headers.

Stop making stupid videos!!!