[Development] Using '#pragma once' instead of include guards?

[Volker Hilsheimer]

> On 14 Oct 2022, at 15:47, Kyle Edwards via Development <development at qt-project.org> wrote:
> 
> On 10/14/22 03:15, Eike Ziller wrote:
>>> However, there are ways to enforce the use of unique header guards. clang-tidy has an extensible header guard check that can be customized per-project, and plugin loading functionality. Qt could create a clang-tidy plugin that sets up this header guard check and enforces a unique-enough header guard in CI.
>> That works to avoid clashes inside a project, but doesn't help if user applications mix Qt + their code + other libraries not under their control, which is similar to the issues of #pragma once.
> 
> My point was that a naming scheme could be enforced that would make it very unlikely for an external project's header guards to conflict with the ones from Qt. I will leave it as an exercise to the reader to come up with such a scheme.
> 
> Kyle


I suppose the original idea was that the ‘Q’ prefix is reserved for things in Qt (I vaguely remember that back in the early 2000s there was some sort of ‘official' list for those prefixes; I might be completely wrong about that though), just as C is the prefix for MFC classes, and T for classes in Turbo C or Symbian C++. But that could never have been more than a convention, and I don’t quite see how anything based on convention can be enforced.

If in the future we add a class QLog or QJack or QDoubleRangeSlider to Qt, then folks that have made the unfortunate choice to use the prefix `Q` when they named their types will be unhappy. Application developers can use Qt in a namespace, but those that provide an SDK themselves won’t be able to solve the issue for users using both their headers and Qt headers.

So if and when that time comes we’ll have to deal with it somehow, case by case. Whether we use `#pragma once` or conventional include guards is then perhaps just a minor problem - that's something either side can change without breaking source or binary compatibility. Would it help if we named our include guards QT_QFOO_H? It would reduce the probability of a clash, but the real problem of two QFoo classes in the global namespace won’t go away.

Anyway, I’ve added the respective text to the coding convention wiki page.

https://wiki.qt.io/Coding_Conventions

Volker