-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mass-rename all relevant sources to a C++ extension #3316
Comments
I'm fine with |
I don't think I've ever come across a .cxx/.hxx extension in any project that I've looked at, but that is a totally fair point. |
CMake itself uses it, and when I first learned C++, I used it for my stuff too. 😅 |
You can also use All the valid extension types are listed on the Wikipedia page for the language. |
I'm also more accustomed to seeing That said, |
I'm not a fan of And case sensitive extensions are evil. No. 😭 |
Oh, I've just realized that the |
Oh, yup. It's also just two characters and somehow that feels wrong. Like, how many file extensions are there with only two characters...
Yeah, that was mostly a joke, please don't choose those 😄 |
Also note that C++ modules will use |
Where is that stated? Based on quick googling around, .ixx seems to be a Visual Studio specific extension. Both gcc and clang have/accept their own litanies (.cppm, .ccm, .cxxm, .c++m and whatnot) 🤪 |
Oh geez, okay whatever, strike that as a reason. 😵 Still, I stand by my original rationale for cxx/hxx. |
Yup, cxx/hxx has the significant benefit that it's the only version with some actual, concrete rationale to back it 😆 I was a little surprised to see the core guidelines recommending .cpp and .h. .cpp is common enough not to raise eyebrows, but .h? Why on earth would one NOT want to differentiate from plain C headers? |
It's somewhat rare these days to have mixed C/C++ headers in a single project, so I can see why they say that. That doesn't mean I agree with it. 😃 |
Isn't that to have a single header file for both C and C++ usage, assuming that you'd wrap the C++ only bits with Edit: Basically what we do right now in our header files 😄 |
As for sharing the same header - yes you can certainly do that. AFAIK neither C or C++ compilers are actually in the slightest interested about the extension, that's all just convention. I would instinctively pick .h for plain C. We have a specific reason to not mix the headers: we don't want to make our C++ API public anytime soon. Having C++ in separate headers also helps editors do syntax highlighting and the like. |
Once you put it down this way... it'd seem foolish to do anything else really. So |
Ack, it seems like sticking to |
Indeed, if it quacks, it's a duck. No point in pretending otherwise 😄 |
Added an AC to the description - lets try to get that habbit rolling too 😄 |
Makes sense to me! Let's do it! |
I'm in the middle of doing this, and seeing all these exes in practise... its just SO EYE-BLEEDING UGLY that I cannot imagine living with this from here on:
|
Making you all cross-eyed is one thing, but those exes actually obscure relevant information: whether a file is a header or a source gets all but lost in there. |
For a side-by-side comparison of the same thing:
Those of us who work on this on daily basis need to think of their health, both mental and physical. There's just no comparison between those three, we'll take the last one and run with it. It's actually a pretty common choice - for example gcc uses .cc/.hh. |
Truly, we've needed to see this from another perspective to notice. Nothing wrong with adapting plans accordingly. |
And nothing in this world prepared me for the onslaught of those exes in the masses 🙈 |
As planned from the start of the C++ journey, rename all C++ files to a C++ extension to remove the confusion for both humans and tooling - so we now get to remove the associated cmake hacks to force it to use a C++ compiler. We initially decided on going for .cxx/.hxx extension on the grounds that it's the technically most right thing to do as it matches with the build toolchain CXX/CXXFLAGS and all that. But at around 1/4 way through the rename I concluded that this is not only eye-bleeding ugly, it also totally obfuscates the difference between headers and sources in the visual noise it creates. Last but not least, it makes you think of All My Ex's Live in Texas, and that's about the last thing in I want to be thinking off. Both the song, and the exes. Those of us working on rpm for a living need to think of their well-being, both mental and physical. The choice of .cc/.hh extension is primarily based on that: the .cxx/.hxx extension proved to be almost revolting in practise. To my total surprise really, I never expected this to matter at all. Maybe others have had similar feelings though, .cc/.hh is one of the more common choices, for example gcc and binutils use that. Fixes: rpm-software-management#3316
4.20 release is nigh (#3271) so as outlined in #3103, the time to do a mass-rename is closing in, this is simply a ticket to allow tracking + planning it. And maybe discuss a bit too.
The main "issue" here is deciding which suffix to use. From what I've seen, .cpp looks like the most common one for modern c++ code and would be in line with dnf5 which doesn't hurt either.
The other question is headers: we'll be dealing with plain C headers from here to eternity, so it seems like it'd be helpful to differentiate what is meant for C vs C++ consumption. .hpp seems like a consisntent and logical suffix there, and also what dnf5 uses. Not that it dictates in any way, but doesn't hurt either because it's a neighbor team really.
AC:
.cc
and C++ -only (ie those without __cplusplus guards) to.hh
. Exempt from this rename areEdit: the initial plan was to use cxx/hxx to match the common variable naming in build systems but the result is not something we can stand looking day after day. Seriously.
The text was updated successfully, but these errors were encountered: