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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
