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

[Kyle Edwards]

On 10/13/22 10:42, Jean-Michaël Celerier wrote:
> >The only way you’d have a strong case with this is if it has some 
> other significant benefit, like compilation speedup.
>
> The main benefit to me is that it entirely removes possibilities for 
> conflict due to headers having the same name. At least Qt takes great 
> care of avoiding this but still, notice that e.g. the authors of 
> Qt3D's Qt3DCore::QTransform had to be careful to not just do #ifndef 
> QTRANSFORM_H
>
> Now what happens when someone develops a different library but with a 
> header guard similar to Qt's?
>
> If I grep into the various cloned projects on my hard drive, for 
> instance I see
>
> #ifndef QRENDERER_H
> #ifndef QGLRENDERER_H
> #ifndef QSEARCHFIELD_H
> #ifndef QLOG_H
> #ifndef QJACK_H
> #ifndef QENC_H
> #ifndef QRANGESLIDER_H
> #ifndef QDOUBLERANGESLIDER_H
>
> etc... is the Qt project 100% confident that it will *never ever* use 
> these names? With pragma once this is a 100% non-problem.

I agree with previous points that while #pragma once can work well for a 
standalone program, it has the potential to cause problems when used in 
libraries that other developers use. Even CMake omitted #pragma once 
from the one (admittedly deprecated) header that may be consumed 
externally (cmCPluginAPI.h).

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.

Kyle