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
42 matches
Mail list logo
