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

Reply via email to