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 
<math...@taschenorakel.de<mailto:math...@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.macie...@intel.com<mailto:thiago.macie...@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@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development

_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to