SF.1: Default convention for C++ header files should be .hpp (matching .cpp) #686
Comments
GiovanniDicanio
changed the title
|
I've never used |
|
Does it really matter? The standard library doesn't have extensions and neither does this library Strangely I use .h on Windows but on Linux I use .hpp. I have never GR Sent from my Nexus 5. On 19 Aug 2016 6:06 p.m., "Galik" notifications@github.com wrote:
|
|
It does really matter not suggesting ".h" as the "good default" for C++ As .cpp is suggested as default for C++ sources, .hpp should be suggested Giovanni Il sabato 20 agosto 2016, Graham Reeds notifications@github.com ha
|
|
While I'm personally always using |
|
We don't feel that we should suggest a major change to status quo, and .h has been used for decades |
|
To add another data point to this conversation, this is a post I wrote in a private thread discussing .hpp for C++ headers, that I thought might be appropriate to repost here:
Consistency is important in projects, so if you are working on a project already using .h for C++ headers or whatever other extension, I agree to continue following that particular extension in that project for the argument of consistency. But for new projects, IMO it's better to suggest a specific C++ extension for headers, considering the elements I tried to expose during this thread. Thanks. |
|
You made a suggestion to recommend your favorite convention. You gave a reason. However, most people (as far as I can tell, the C++ community is HUGE) have not found the various arguments for .hpp compelling eventhough your convention and the arguments you offer have been known and used for at least a couple of decades. I prefer not to mess with status quo unless there is a significant chance of success and the issue is among the ones that I think would give the most benefits to the community. The arguments for a change must always be stronger than for status quo because it takes work, efforts, and resources to make a change. I have worked on projects that used .h, on projects that used .hpp, and on projects that used .H. I did not notice the choice of suffix to be among the significant problems or advantages. So, I prefer to spend my efforts on other things. Boost is a nice and prominent collection of libraries, but it is just one library. Boost's use of .hpp is not in itself a proof of anything beyond "something like this can work", and we already knew that long before Boost. The committee decided against using suffices for headers partly to avoid having to make a choice among suffices and partly because there is no guarantee that a header is a text file. Different encodings of the header information may use different suffices when stored as files. This becomes interesting/relevant once we move to a world of modules. There might be different module encodings, so we are likely to use import and export directives that do not use suffices (with a mapping to files with suffices behind the scenes in the implementation). Unfortunately, modules are not yet sufficiently widely available for us to base the Guidelines on them, but it may be time to start thinking about guidelines for a transition to modules. I'd love to se a rule "Use mudules, rather than directly #including headers." |
|
A small bit of data on this topic. I've been researching the topic as it's something I have been mulling for a while:
|
|
@johnthagen I too advocate for using
so you're free to use whichever you (and I) prefer 😉. Maybe over time, by small collective efforts such as yours, @GiovanniDicanio's and others, |
|
I believe the common is by far to use .h for headers. Once you enter in the .hpp for C++, sombody will suggest .tpp (or templates), .inl for inline definitions and so on. Keep it simple! |
|
On the flip side: I end up working with many mixed C/C++ projects. Using ".h" for everything makes it pretty unclear whether a module is safe to use from a C context or not. At least hpp gives me an immediate clue as to the language support.
… On Jul 17, 2017, at 13:10, J. Daniel Garcia ***@***.***> wrote:
I believe the common is by far to use .h for headers.
Once you enter in the .hpp for C++, sombody will suggest .tpp (or templates), .inl for inline definitions and so on.
Keep it simple!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I'll join @phillipjohnston. It makes sense to use extensions .c and .h for C files, @jdgarciauc3m I really doubt that will encourage or lead to other extensions. |
|
Does mixed C/C++ project mean including iostream from .C files? Will .hpp make iostream and cout significantly more popular than stdio and printf within .cpp files? When differentiation is so badly needed, early adoption of modules proposal might be better alternative. |
|
I work on embedded systems, so mostly when it's mixed C/C++ it's just dealing with large portions of (probably legacy) C code. Not from the sense of using C++ constructs from .c files. Depending on the project's size and momentum, not all of the code may be compiled with a C++ compiler. I also am not going to die on any hill regarding header file type conventions :). I'm just providing an example of how using the same header file type (.h) for two distinct languages can be very confusing. Especially when the languages can sometimes, but not always, inter-operate. |
|
The rationale for using a different extension for C++ source files is that some tools will easily recognize if the translation unit is C or C++. This is why we use .cpp (or some others like .cxx). The most common case is a build system determining if the C or the C++ compiler should be used. This does not apply to header files, as they will be included (directly or indirectly) from some source file (i.e. some .cpp file). |
|
This *does* apply to header files as well!
In fact, see e.g. the Clang/LLVM guideline point on header files:
https://llvm.org/docs/CodingStandards.html#file-headers
…---begin---
The “-*- C++-*-” string on the first line is there to tell Emacs that the
source file is a C++ file, not a C file (Emacs assumes .h files are C files
by default).
---end---
Of course, using a specific extension differentiating C headers from C++
headers would have been better (instead of adding a "magic" comment in the
headers), just like we differentiate .c from .cpp files.
GD
Il giorno mer 19 lug 2017 alle 11:40 J. Daniel Garcia <
notifications@github.com> ha scritto:
The rationale for using a different extension for C++ source files is that
some tools will easily recognize if the translation unit is C or C++. This
is why we use .cpp (or some others like .cxx). The most common case is a
build system determining if the C or the C++ compiler should be used.
This does not apply to header files, as they will be included (directly or
indirectly) from some source file (i.e. some .cpp file).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#686 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEeal1QARSfeU_LH_hyjA2e65OfMDQjyks5sPc8VgaJpZM4JomHI>
.
|
|
Obviously there's no convention that will please everybody. It seems to me that that this discussion is not going anywhere. |
|
To me, the point is not which particular extension to pick for C++ headers
(.hpp, .hh, ...), just like we can pick several valid extensions for C++
sources (.cpp, .cc, ...).
My point is to *differentiate* C++ headers from C headers, just like we
differentiate C++ sources from C sources using *different* extensions.
Il giorno mer 19 lug 2017 alle 12:51 Jonathan Wakely <
notifications@github.com> ha scritto:
… Obviously there's no convention that will please everybody. It seems to me
that that this discussion is not going anywhere.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#686 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEeal-8HaCbUewx9i-SF7UiLinkCLCyhks5sPd_CgaJpZM4JomHI>
.
|
|
I would like to add my opinion to this discussion, even if it is marked as closed, and hope that some things might get reconsidered. The first thing I do not like in the reasoning is that this guideline is proposed because of legacy. The second issue is that some guidelines state that C and C++ are different languages. Telling people to use c filenames seems to go against those rules, after all that's the reason why we use The second think that I dislike is that there are some advantages by using a different file ending, but those are not mentioned. As already mentioned, clang could take advantage of it without using internally magic strings, but other tools too of course.
Other static analyzers, (most of C++ static analyzers also works on C code), could, like clang take advantage of that. And there are probably other use cases (different conventions for file editors, mime type registration in the OS, ...) that I did not think of. Another couple of considerations: Modules are not really an option/alternative. Using Of course being consistent is important, but IMHO it is also relatively easy to change this convention even in a big codebase. Similarly the same can be done for filenames. If the use-case is more complicated, because some (but not all) headers are really ment to be used in C projects too, then you already have the problem that you need, every time you open a header file, to understand if it is a C or C++ header file, and if it compiles with both compilers when you make a change. If a file is used by a library and we can't therefore just rename it, without clients having to adapt their code, it is always possible to rename it, and provide a "deprecated" .h file that includes the It is also possible to update the file name convention every time a file is updated. To conclude: If we really do not want to tell people how to name their files (as Bjarne already stated in this discussion), then we should also not tell them to name it with a Therefore I would like to propose to update the guideline in something like: |
|
N.B. that should say "C and C++" not "c and c++", and "fewer" not "less". Renaming files can make it harder to follow history in version control, and so can cause problems of its own. As with all guidelines in the NL section, if you have a different preference or follow a different convention, ignore the guideline. The intro to that section is clear about that. |
|
Just because a guideline can be ignored by an individual, does not mean that there is no room to improve it. |
I consider this statement at best, correct, but at worst, harmful. I think: if it feels wrong to add a note about E: Also FWIW I don't think this is bike-shedding. Lots of tools like |
FWIW, I've run into this exact problem when developing a Cppcheck plugin for CLion. Each file is analyzed independently and when looking at a The concerns others have raised about code churn and status quo are legitimate, though. |
|
I also think, There is nothing wrong in recognizing and allowing established practice, but that shouldn't stop guidelines from recommending better alternatives for situations, where consistency is not an issue. Most counterarguments seem to be: "We don't want to force users to make big changes unless there is a big benefit to it". Well, no one is suggesting a mandatory core-guideline-checker that will complain on every However, for new or small projects, using a distinct extension for c++ headers comes at pretty much zero cost and has the advantage of clearly documenting intent to both tools (no need for magic strings in the file) and other users. From the possible alternatives ( As a final thought: Even if you don't want to change the recommendation, personally, I would shrink the whole section down to SF.1: Use a .cpp suffix for code files and .h for interface files if your project doesn't already follow another convention Reason Note Enforcement
Anything else is either unrelated (like the examples) or distracts from the main reason of following existing practice (like the note about c-headers being used in c++ projects) and leads to more bikeshedding. Sometimes less is more. |
…es, also removed the PP from the end of the inclusion guards where applicable. Renamed header extensions back to .h from .hpp as suggested by Bjarne Stroustrup when suggested to add header file extensions as .hpp as a standard isocpp/CppCoreGuidelines#686 (comment) Changed all #include statements to point to the newly renamed headers. Got it back up to the compile status before the rabbit hole.
…es, also removed the PP from the end of the inclusion guards where applicable. Renamed header extensions back to .h from .hpp as suggested by Bjarne Stroustrup when suggested to add header file extensions as .hpp as a standard isocpp/CppCoreGuidelines#686 (comment) Changed all #include statements to point to the newly renamed headers. Got it back up to the compile status before the rabbit hole.
Having a specific “.hpp“ extension (like Boost does) for C++ headers (matching the “.cpp“ extension) makes the C++-specific nature of the header very clear.
Moreover, editors and tools can understand simply looking at the extension that it's a C++ header instead of a pure C header. In this way, rules like this one requesting a “magic string“ to clarify that an header is C++ (not C) are made useless:
The “.h” extension should be used for header files that contain pure C declarations, and are intended to be read by C and/or C++ (like
<stdio.h>,<Windows.h>, or custom headers exposing pure C interfaces). The “.hpp” extension should be used for header files that contain C++ stuff (e.g.: class declarations and/or inline implementations) and are not intended for C.The text was updated successfully, but these errors were encountered: