On Wednesday 29 January 2025 09:54:05 Pacific Standard Time Marc Mutz via
Development wrote:
> Additionally, in light of recent findings where two modules used
> identical header guard macros, I'm again proposing to prefix installed
> header guard macro names with the module name:
>
>QUTIL_H
qt can ideally rely on an explicit decision that has
>>>> become manifest through an easily recognizable pattern in each header
>>>> file. Whether we replace include guards with #pragma in all non-public
>>>> headers, or tag all public headers with a comment doesn’
that much, does it?
>>>
>>> But given that we have the “We mean it” comment already for _p.h
>>> headers, would it not be more consistent if we simply add that comment
>>> to all non-public headers (no matter their file path, and no matter
>>> whether the header is installed or not)? That comment makes the
>>> usability of t
ehalf of
Marc Mutz via Development
*Sent:* Thursday, February 29, 2024 11:02
*To:* development@qt-project.org
*Subject:* Re: [Development] Using '#pragma once' instead of include
guards?
Hi,
DL;DR: Use #pragma once in all non-installed headers
The question recently came up "wha
> to all headers not declaring public API is less obscure? The question is
> if and how we can use syncqt to enforce this reliably.
>
>
> Volker
>
>
>
>>
>> *From:* Development on be
On Tue, Mar 05, 2024 at 10:43:50AM +, Volker Hilsheimer via Development
wrote:
> > On 4 Mar 2024, at 15:56, Kai Köhne via Development
> > wrote:
>
> > Hi Marc,
> > I've nothing against using '#pragma once' for private/internal headers.
> > But you said you mainly want to have this to di
> On 5. Mar 2024, at 11:43, Volker Hilsheimer via Development
> wrote:
>
>> On 4 Mar 2024, at 15:56, Kai Köhne via Development
>> wrote:
>>
>> Hi Marc,
>>
>> I've nothing against using '#pragma once' for private/internal headers.
>>
>> But you said you mainly want to have this to differen
From: Development on behalf of Marc Mutz
via Development
Sent: Thursday, February 29, 2024 11:02
To: development@qt-project.org
Subject: Re: [Development] Using '#pragma once' instead of include guards?
Hi,
DL;DR: Use #pragma once in all non-installed headers
The question re
Development on behalf of Marc Mutz
via Development
Sent: Thursday, February 29, 2024 11:02
To: development@qt-project.org
Subject: Re: [Development] Using '#pragma once' instead of include guards?
Hi,
DL;DR: Use #pragma once in all non-installed headers
The question recently came up &qu
Hi,
DL;DR: Use #pragma once in all non-installed headers
The question recently came up "what is a private header". And the answer
isn't just "_p.h, of course". We have tons of headers that are "private"
without being marked as such with _p.h and "We mean it." comment.
The first realization is
On Mon, 10 Oct 2022 at 13:13, Hasselmann Mathias
wrote:
>
> I am surprised by the question: "It's non-standard and it's behavior is
> undefined" actually should be enough to avoid such feature.
>
> Actually if a reliable implementation of "#pragma once" would be
> possible, that feature would have
Once we had QString and QByteArray (and the admittedly ill-conceived
QStringRef). Now we have QStringView, QAnyStringView, QByteArrayView,
... and when asking what the prefered getter/setter-signature for
"Qt-style" interfaces is the answer I get is "We'd guess $X, but the
only guy that knows for
On Wed, Nov 02, 2022 at 02:25:25PM +, Marc Mutz via Development wrote:
> Hi Volker,
>
> On 14.10.22 17:12, Volker Hilsheimer via Development wrote:
> > Anyway, I’ve added the respective text to the coding convention wiki
> > page.
> > https://wiki.qt.io/Coding_Conventions
>
> Having read the
On Wednesday, 2 November 2022 07:25:25 PDT Marc Mutz via Development wrote:
>QT_GUARD_INCLUDE_OF___
>
> Example:
>
>QT_GUARD_INCLUDE_OF_QTCORE_IO_QIODEVICE_H
We don't need to make it THAT verbose. But inserting the module name makes
sense, because the "official" include is .
I'd also s
> On 2 Nov 2022, at 15:25, Marc Mutz via Development
> wrote:
>
> Hi Volker,
>
> On 14.10.22 17:12, Volker Hilsheimer via Development wrote:
>> Anyway, I’ve added the respective text to the coding convention wiki
>> page.
>> https://wiki.qt.io/Coding_Conventions
>
> Having read the thread in
Hi Volker,
On 14.10.22 17:12, Volker Hilsheimer via Development wrote:
> Anyway, I’ve added the respective text to the coding convention wiki
> page.
> https://wiki.qt.io/Coding_Conventions
Having read the thread in total, I'm surprised about this outcome.
AFAIK, we haven't had problems with tr
> On 14 Oct 2022, at 15:47, Kyle Edwards via Development
> wrote:
>
> On 10/14/22 03:15, Eike Ziller wrote:
>>> 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 f
On 10/14/22 03:15, Eike Ziller wrote:
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 che
> On 13 Oct 2022, at 16:56, Kyle Edwards via Development
> wrote:
>
> 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 entirel
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
>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
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 co
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 wrote:
On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development wrote:
Speaking as co-maintainer of CMake, we have effectively
Am 11.10.2022 um 21:20 schrieb Kevin Kofler via Development:
"locking you down to a vendor" is a funny argument when the Wikipedia
article:
https://en.wikipedia.org/wiki/Pragma_once
cannot name a single compiler that does not support #pragma once, and 20
that do.
Yes, it is supported in a way
> On 11 Oct 2022, at 22:11, Thiago Macieira 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 polic
On 2022-10-11 22:04, Thiago Macieira wrote:
...
// This macro can be used to calculate member offsets for types with a non
standard layout. // It uses the fact that offsetof() is allowed to support
those types since C++17 as an optional // feature. All our compilers do
support this, but some iss
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-ti
On Monday, 10 October 2022 13:14:19 PDT Scott Bloom wrote:
> The main issue I have, is we build a tool with tons of sub libraries and
> modules, with a pretty poor build environment. We have 800+ developers
> using it, so any change is done by a committee and takes years ☹
>
> Our Qt gets places
On Tuesday, 11 October 2022 12:31:36 PDT Alejandro Exojo wrote:
> I suggest that you don't look at the implementation of things like
> Q_OFFSETOF, then. ;-)
>
> // This macro can be used to calculate member offsets for types with a non
> standard layout. // It uses the fact that offsetof() is allo
On Mon, Oct 10, 2022, at 12:11 PM, Hasselmann Mathias wrote:
> I am surprised by the question: "It's non-standard and it's behavior is
> undefined" actually should be enough to avoid such feature.
I suggest that you don't look at the implementation of things like Q_OFFSETOF,
then. ;-)
// This m
On 10/10/22 05:55, Volker Hilsheimer via Development wrote:
Hi,
We are using `#pragma once` in a number of examples and tests in the Qt source
tree, but I don’t think we have officially endorsed it in favour of explicit
include guards.
#pragma once is “non-standard but widely supported” [1],
Paul Colby wrote:
> Also worth considering
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-guards
>
> SF.8:
>
>> Note Some implementations offer vendor extensions like #pragma once
>> as alternative to include guards. It is not standard and it is not
>> portable. It injects the
On Monday, 10 October 2022 13:20:56 PDT Henry Skoglund wrote:
> But perhaps there could be use of #pragma once anyway, as a way to
> detect those duplicate files? Say something like this at the top of an
> .h file:
>
> #pragma once
> #if defined QGLOBAL_H
> #error "Multiple instances of qglobal.h
Also worth considering
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-guards
SF.8:
> Note Some implementations offer vendor extensions like #pragma once
> as alternative to include guards. It is not standard and it is not
portable.
> It injects the hosting machine’s filesystem se
On 2022-10-10 21:27, Thiago Macieira wrote:
...
This situation is annoying either way. With include guards, you will get a
working build, but you may spend some time trying to figure out why the changes
you're making to the headers aren't taking effect. With the pragma, you get
hard build errors
companies that do multi-platform development
but store their Qt versions on a server.
Scott
-Original Message-
From: Development On Behalf Of Volker
Hilsheimer via Development
Sent: Monday, October 10, 2022 2:55 AM
To: development@qt-project.org
Subject: [Development] Using &#x
On Monday, 10 October 2022 08:43:53 PDT Christian Kandeler via Development
wrote:
> On 10/10/22 17:13, Thiago Macieira wrote:
> > The biggest problem we used to have was installing builds that had
> > include
> > paths pointing to both the source and installation directory. With
> > preprocessor g
On 10.10.2022 12:07, Eike Ziller via Development wrote:
From what I see, it should in practice be ok to use. But perhaps I’m missing
something. Does anything speak against using ‘#pragma once’ in new files?
Just for reference, we are using it without issues in Qt Creator since 2016.
(But of
On 10/10/22 17:13, Thiago Macieira wrote:
The biggest problem we used to have was installing builds that had
include
paths pointing to both the source and installation directory. With
preprocessor guards, only one of the two would actually get included; with
#pragma once, the files are actually
On Monday, 10 October 2022 02:55:20 PDT Volker Hilsheimer via Development
wrote:
> Hi,
>
>
> We are using `#pragma once` in a number of examples and tests in the Qt
> source tree, but I don’t think we have officially endorsed it in favour of
> explicit include guards.
> #pragma once is “non-st
> -Original Message-
> From: Development On Behalf Of
> Volker Hilsheimer via Development
> Sent: Monday, 10 October 2022 5:55 PM
> To: development@qt-project.org
> Subject: [Development] Using '#pragma once' instead of include guards?
>
> Hi,
>
I am surprised by the question: "It's non-standard and it's behavior is
undefined" actually should be enough to avoid such feature.
Actually if a reliable implementation of "#pragma once" would be
possible, that feature would have been included in the C++ standard for
a long time already, woul
> On 10 Oct 2022, at 11:55, Volker Hilsheimer via Development
> wrote:
>
> Hi,
>
>
> We are using `#pragma once` in a number of examples and tests in the Qt
> source tree, but I don’t think we have officially endorsed it in favour of
> explicit include guards.
>
> #pragma once is “non-stan
Hi,
We are using `#pragma once` in a number of examples and tests in the Qt source
tree, but I don’t think we have officially endorsed it in favour of explicit
include guards.
#pragma once is “non-standard but widely supported” [1], with some caveats,
e.g. when there are multiple header files
On Monday, 8 October 2018 09:12:26 PDT Matthew Woehlke wrote:
> On 08/10/2018 02.23, Henry Skoglund wrote:
> > So, what about a new preprocessor command:
> >
> > __has_same_md6_digest
>
> See also http://wg21.link/p0538 and note that EWG rejected it. The
> general consensus, AFAICT, is that modul
On 2018-10-08 18:12, Matthew Woehlke wrote:
On 08/10/2018 02.23, Henry Skoglund wrote:
So, what about a new preprocessor command:
__has_same_md6_digest
See also http://wg21.link/p0538 and note that EWG rejected it. The
general consensus, AFAICT, is that modules is expected to make all this
st
On 08/10/2018 02.23, Henry Skoglund wrote:
> So, what about a new preprocessor command:
>
> __has_same_md6_digest
See also http://wg21.link/p0538 and note that EWG rejected it. The
general consensus, AFAICT, is that modules is expected to make all this
stuff irrelevant, and therefore EWG does not
On Monday, 8 October 2018 01:50:04 PDT Edward Welbourne wrote:
> On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote:
> >> Just a quick question: Does anybody have any good arguments against
> >> us starting to use #pragma once instead of header guards throughout
> >> our code base?
>
> Thiago
On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote:
>> Just a quick question: Does anybody have any good arguments against
>> us starting to use #pragma once instead of header guards throughout
>> our code base?
Thiago Macieira (7 October 2018 20:39) wrote:
> For example, I have ~/src as a bi
On 2018-10-08 07:13, Thiago Macieira wrote:
On Sunday, 7 October 2018 15:17:30 PDT Henry Skoglund wrote:
I recommend against changing Qt.
Hi, but isn't C++17's __has_include preprocessor cmd an implicit
endorsement of #pragma once? I mean, they both assume that the file
namespace is stable and
On Sunday, 7 October 2018 15:17:30 PDT Henry Skoglund wrote:
> > I recommend against changing Qt.
>
> Hi, but isn't C++17's __has_include preprocessor cmd an implicit
> endorsement of #pragma once? I mean, they both assume that the file
> namespace is stable and idempotent.
No, I don't see how on
On 2018-10-07 20:39, Thiago Macieira wrote:
On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote:
Hi,
Just a quick question: Does anybody have any good arguments against us
starting to use #pragma once instead of header guards throughout our code
base?
Yes, two:
a) not supported everywher
On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote:
> Hi,
>
> Just a quick question: Does anybody have any good arguments against us
> starting to use #pragma once instead of header guards throughout our code
> base?
Yes, two:
a) not supported everywhere
b) not well-defined behaviour when i
On 2018-10-07 09:56, Lars Knoll wrote:
IMO #pragma once is both safer and nicer to use than classic header
guards.
Regarding safety, clang has -Wheader-guard which catches typos in header
guards, so most of our codebase should be ok.
(Would be nice to have clang-cl -Werror builds on our Windo
> On 7 Oct 2018, at 15:18, Sérgio Martins wrote:
>
> On 2018-10-07 09:56, Lars Knoll wrote:
>> Hi,
>> Just a quick question: Does anybody have any good arguments against us
>> starting to use #pragma once instead of header guards throughout our
>> code base?
>
> Hi Lars,
>
>
> This was alread
On 2018-10-07 09:56, Lars Knoll wrote:
Hi,
Just a quick question: Does anybody have any good arguments against us
starting to use #pragma once instead of header guards throughout our
code base?
Hi Lars,
This was already discussed back in January:
https://lists.qt-project.org/pipermail/devel
quot;Qt development mailing list"
Sent: 07/10/2018 10:56:47
Subject: [Development] Using #pragma once
Hi,
Just a quick question: Does anybody have any good arguments against us
starting to use #pragma once instead of header guards throughout our
code base?
I’ve started using it implicitly
On Sun, Oct 07, 2018 at 08:56:47AM +, Lars Knoll wrote:
> Hi,
>
> Just a quick question: Does anybody have any good arguments against us
> starting to use #pragma once instead of header guards throughout our
> code base?
Not me.
> I’ve started using it implicitly when updating 3rd party cod
Hi,
Just a quick question: Does anybody have any good arguments against us starting
to use #pragma once instead of header guards throughout our code base?
I’ve started using it implicitly when updating 3rd party code (the macro
assembler) in qtdeclarative without any problems (so I’d supported
59 matches
Mail list logo
