Proposal to swap include gaurds to `#pragma once`

General Discussion
1

TLDR: I am willing to change all the Macro include guards to #pragma once, and would like feedback on if this would be a welcomed change or not.

Preface:
I want to preface by saying I know that this is not a necessary change and also that it is more of a preference anyway. I am just here to help however I can, so I am happy to leave as is if that’s preferred.

Discussion:
I couldn’t find a discussion about this, so I wanted to bring it up to get feedback on the idea. I am aware that #pragma once is not officially in the c++ standard, however, all the major compilers support it. I think it makes the intent clear and far easier to read, but I also understand that the project may wish to strictly conform to the standard hence the post here.

How I came across:
I am working on a branch on my fork of avogadrolibs that cleans up code and makes a lot of simple changes for readability, including:

  • #typedef to using (where appropriate)
  • proper default constructor and destructor declarations
  • unused include removal
  • missed pointer/ref type declarations on auto statements
  • concatenated namespaces
  • clear typecasting errors
  • etc

I would be happy to tack the #pragma once change on as well with these.

1 Like
2

I’m inclined to say no because there are at least a few files with identical filenames, which IIRC can confuse #pragma once (e.g. c++ - #pragma once vs include guards? - Stack Overflow)

For example, core/molecule.h and qtgui/molecule.h differ – the latter is a subclass of the former.

If #pragma once no longer has problems with identical header filenames, I’d be willing to give it a try. (But I’d suggest a separate pull request so we can check it out.)

1 Like
3

Fair enough, quite honestly I don’t know how it preforms with duplicate filenames as I hadn’t run into that issue on any projects as of late. This is something I didn’t consider, so I appreciate the feedback. I will focus on finishing up with the changes I am already working on, then I will test it out on a separate branch as suggested. I will post again if it compiles and passes.

1 Like
4

Awesome. The other changes you’re mentioning would be most welcome.