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

[Jean-Michaël Celerier]

>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.


On Thu, Oct 13, 2022 at 9:10 AM David Skoland via Development <
development at qt-project.org> wrote:

> Hi,
>
> Using #pragma once does make assumptions about filesystems and compilers,
> which in turn makes assumptions about how Qt is installed and included
> (and we’ve seen a handful of…. creative examples of both).
>
> This results in risk to developers who *use* Qt (many), which must be
> weighed against convenience for developers who *develop* Qt (few). It
> seems like a hard sell. The only way you’d have a strong case with this is
> if it has some other significant benefit, like compilation speedup.
>
> Cheers,
> David Skoland
>
> On 12 Oct 2022, at 13:25, Hasselmann Mathias <mathias at taschenorakel.de>
> wrote:
>
> Sounds like an excellent plan.
>
> Ciao
> Mathias
>
> Am 12.10.2022 um 12:35 schrieb Volker Hilsheimer via Development:
>
> On 11 Oct 2022, at 22:11, Thiago Macieira <thiago.macieira at intel.com>
> wrote:
>
> On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development
> wrote:
>
> Speaking as co-maintainer of CMake, we have effectively required #pragma
> once to build CMake itself since August 2017, we officially codified
> this as policy in September 2020, and we will soon be writing a
> clang-tidy plugin to enforce this in our CI. We have not received any
> complaints about it. Just my $0.02.
>
> Thanks for the information. This confirms what we already knew that all
> systems
> and compilers where Qt would be compiled do support it.
>
> However, neither Qt Creator nor CMake are libraries. They are not
> comparable.
>
>
> Thanks all for sharing your insights and digging up the previous
> discussions as well.
>
> The summary of all this then seems to be:
>
> - ok to use '#pragma once’ in headers that are not designed to be included
> by Qt users, i.e. in tools, applications, examples and demos, tests
> - for everything else, in particular for public and, for consistency’s
> sake - private headers in Qt, we continue to use conventional include guards
>
> Rationale: #pragma once is not well enough defined and not part of the
> standard, and we cannot make any assumptions about how Qt is installed,
> used as part of a larger SDK etc. So best to stay conservative.
>
> If that’s not entirely off, then I’d like to put this into
> https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new
> thread on this topic in a few years.
>
> Volker
>
> [1]: And since that page seems rather outdated - e.g. we do use
> dynamic_cast in Qt today, and the suggestion to normalize signals and slots
> should rather suggest to make connections via PMF syntax - perhaps it’s
> time to move this to a QUIP where we can discuss and review such changes in
> gerrit. I won’t have time to do that for a while (perhaps ditto for
> https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to
> give this a shot.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20221013/d130d82e/attachment.htm>