Re: [Development] Using '#pragma once' instead of include guards?
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 detected" > #endif > #define QGLOBAL_H > ... I thought of that but didn't write in my reply because, though it helps identify the problem, it doesn't help the poor non-developer who ran into the problem. They'll still get hard errors either way, probably several screenfuls of them. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
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 semantics into your program, > in addition to locking you down to a vendor. Our recommendation is to write > in ISO C++: See rule P.2. Cheers. On Tue, 11 Oct 2022, 7:23 am Henry Skoglund, wrote: > 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 due to redefined types, probably with both paths so > you'd > > notice easily that there are two copies. > > > > The problem I have with switching to #pragma once is for whom the problem > > happens and who gets to fix it. Most people who build Qt from source are > not > > developing or modifying it; they're simply building for use in their own > > content. So if the problem of incorrect include paths happens with > > preprocessor guards, most likely they will not see any ill effect > because both > > copies of headers are the same. But if those headers use #pragma once, > those > > people will get build errors despite the file contents being identical, > because > > they are different files. > > Hi, this kind of reminds me of detecting violations of ODR but instead > of objects it's about .h files. And #pragma once can then be seen as the > weaker sibling of the include guard mechanism, i.e. not as efficient as > detecting multiple instances of the same .h file. > 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 detected" > #endif > #define QGLOBAL_H > ... > > Rgrds Henry > > ___ > Development mailing list > 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
Re: [Development] Using '#pragma once' instead of include guards?
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 due to redefined types, probably with both paths so you'd notice easily that there are two copies. The problem I have with switching to #pragma once is for whom the problem happens and who gets to fix it. Most people who build Qt from source are not developing or modifying it; they're simply building for use in their own content. So if the problem of incorrect include paths happens with preprocessor guards, most likely they will not see any ill effect because both copies of headers are the same. But if those headers use #pragma once, those people will get build errors despite the file contents being identical, because they are different files. Hi, this kind of reminds me of detecting violations of ODR but instead of objects it's about .h files. And #pragma once can then be seen as the weaker sibling of the include guard mechanism, i.e. not as efficient as detecting multiple instances of the same .h file. 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 detected" #endif #define QGLOBAL_H ... Rgrds Henry ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
My two bits as a user of Qt. Please make sure any exposed headers use the old-school guards and NOT the #pragma once. I don’t care how the internal Qt headers work. However, Ive been burned too many times by the "known issues" of the #pragma once to want to use them. The problem isn’t if the two headers are the same, the problem is it not compiling because of multiple definitions of classes. 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 in a area everyone gets access to. Ie /usr/local/shared_data/Qt on linux and a mount Q:/Qt/ on windows, but Q: can all be accessed via //SHAREPOINT/shared_data/Qt Under Qt might be Qt5.12.9 and Qt5.15.10, but for this example lets assume its not versioned. Under each version, we then have the compiler sub directories. Meaning win64VC15, linux_x86_64/debug and linux_x86_64/release. The windows disty contains debug and release. What happens, is the compiler does not see Q:/Qt/win64VC15/include as the same path as //SHAREPOINT/shared_data/Qt/ win64VC15/include. This is a known issue. I 100% understand that we should fix out build system so they only access any data in the shared_data mount the same way. However that is simply easier said than done relying on #pragma once just fails for us. Ive seen this issue at a number of 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 '#pragma once' instead of include guards? 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 with the same name (which each compiler then handles differently, as there is no standard). 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? Volker [1] https://en.wikipedia.org/wiki/Pragma_once ___ Development mailing list 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
Re: [Development] Using '#pragma once' instead of include guards?
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 guards, only one of the two would actually get included; with > > #pragma once, the files are actually different so both would get included, > > causing a build error. > > Was this really verified or just a guess? Use of #pragma once is rather > wide-spread, and so is implementing header precedence via include path > order, so one would think lots of project would have problems if that > combination didn't work. Anecdotal, because we don't use #pragma once so any such effects would be hidden. But I do remember at some point in the last decade and a half seeing -I options pointing to both the install target path and the source path, so if you're doing a rebuild, you'd find yourself in this situation. The other problem was if people erroneously did make install for a non-installing build; if you did that, then the headers would be copied to include/ and you'd have stale copies. Looking at my Qt build with an install prefix, I don't see any -I pointing to the install path, so there's no problem for me... ...but this build is one out of qt5.git. A split-module build WOULD have this problem for any module besides qtbase. For example, building QtQml must necessarily have the -I for the include dir containing the QtCore subdir. If you've already built and installed QtQml, then that same dir contains a QtQml subdir and all includes can resolve there, depending only on the order of -I flags. Another example was when we had the CMake build copying headers for the bootstrap build, to avoid the issue of bootstrap recompiling itself and moc, and thus every single moc output, every time you modified a file that the bootstrap used. This was a short-lived solution and reverted because I promised that QtCore developers would simply use -DQT_FORCE_FIND_TOOLS=ON with another build to avoid the inconvenience. 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 due to redefined types, probably with both paths so you'd notice easily that there are two copies. The problem I have with switching to #pragma once is for whom the problem happens and who gets to fix it. Most people who build Qt from source are not developing or modifying it; they're simply building for use in their own content. So if the problem of incorrect include paths happens with preprocessor guards, most likely they will not see any ill effect because both copies of headers are the same. But if those headers use #pragma once, those people will get build errors despite the file contents being identical, because they are different files. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
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 course our platform and compiler requirements are more restricted than for Qt.) The same is true for the Pelagicore/Qt ApplicationManager: this project started in 2014 and only ever used "#pragma once" since, and we kept that even when it became an official Qt module. No problems whatsoever, neither with qmake or cmake. cu Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
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 different so both would get included, causing a build error. Was this really verified or just a guess? Use of #pragma once is rather wide-spread, and so is implementing header precedence via include path order, so one would think lots of project would have problems if that combination didn't work. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
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-standard but widely supported” [1], with some caveats, > e.g. when there are multiple header files with the same name (which each > compiler then handles differently, as there is no standard). > 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? 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 different so both would get included, causing a build error. Now, with CMake I think our include paths are a lot cleaner so this may no longer be a problem. I should also point out that the qglobal.h include mess, which we're trying to disentangle, may still require some guards and not #pragma once. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Remaining tools in CMAKE_INSTALL_BINDIR
My question was for the developer's own plugins. Are these tools meant for the developer to test their QML importing their plugins? It might be surprising that it cannot find the plugins they've just installed to QML_PLUGIN_PATH, or worse, finds an older version of them. Indeed if you actually have both Qt5 and Qt6 available, a single qml or qmlscene executable cannot cover them both. So, let's make them versioned. best regards, Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
> -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, > > > 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 with the same name > (which each compiler then handles differently, as there is no standard). > > 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? FYI, there was a discussion about this a few years back: https://lists.qt-project.org/pipermail/development/2018-October/033726.html > > Volker > > [1] https://en.wikipedia.org/wiki/Pragma_once > > ___ > Development mailing list > 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
Re: [Development] Using '#pragma once' instead of include guards?
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, wouldn't it? Ciao Mathias Am 10.10.2022 um 11:55 schrieb Volker Hilsheimer via Development: 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 with the same name (which each compiler then handles differently, as there is no standard). 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? Volker [1] https://en.wikipedia.org/wiki/Pragma_once ___ Development mailing list 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
Re: [Development] Using '#pragma once' instead of include guards?
> 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-standard but widely supported” [1], with some caveats, > e.g. when there are multiple header files with the same name (which each > compiler then handles differently, as there is no standard). > > 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 course our platform and compiler requirements are more restricted than for Qt.) -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Using '#pragma once' instead of include guards?
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 with the same name (which each compiler then handles differently, as there is no standard). 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? Volker [1] https://en.wikipedia.org/wiki/Pragma_once ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
