Guidence on #pragma once

Robert Ramey

23 Nov 2018 23 Nov '18

11:36 p.m.

In the safe numerics library my *.hpp files start with the following boiler plate: #ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif ... I would like to replace all this in every file with just #pragma once according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9 this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray. I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this. Robert Ramey

Show replies by date

Emil Dotchevski

23 Nov 23 Nov

11:54 p.m.

On Fri, Nov 23, 2018 at 3:36 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

In the safe numerics library my *.hpp files start with the following boiler plate:

#ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP

// MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif

...

I would like to replace all this in every file with just

#pragma once

according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9

this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray.

I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits

It will not have any performance benefits. Besides non-standard, #pragma once is unreliable because it is not always trivial for a compiler to detect that it is processing the same file for a second time. My understanding is that in some cases it might not be possible. Secondly, it is possible for the same file to appear in multiple places. You can remove some cruft by deleting the #pragma once. :)

Steven Watanabe

24 Nov 24 Nov

12:01 a.m.

AMDG On 11/23/2018 04:36 PM, Robert Ramey via Boost wrote:

...

In the safe numerics library my *.hpp files start with the following boiler plate:

#ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP

// MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif

...

I would like to replace all this in every file with just

#pragma once

<snip> It would be interesting to know what others might have to say about this.

I never use #pragma once. It just isn't compelling enough to make me write non-standard code. In Christ, Steven Watanabe

Andrey Semashev

1:01 a.m.

On Sat, Nov 24, 2018 at 2:36 AM Robert Ramey via Boost wrote:

...

In the safe numerics library my *.hpp files start with the following boiler plate:

#ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP

// MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif

...

I would like to replace all this in every file with just

#pragma once

according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9

this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray.

I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this.

There is BOOST_HAS_PRAGMA_ONCE in Boost.Config if you want to use the pragma. It should be noted though that most more or less recent compilers already recognize include guards and implement the same kind of optimizations that were provided by `#pragma once` before. And since `#pragma once` is non-standard and not reliable, there's little reason to keep using it, especially if you're targeting newer compilers supporting C++14. So if you want to simplify the code, keep the include guards and drop the pragma.

Olaf van der Spek

25 Nov 25 Nov

12:46 p.m.

On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost wrote:

...

since `#pragma once` is non-standard and not reliable, there's little

Who has a sane reproducible test case showing the claimed unreliability?

...

reason to keep using it, especially if you're targeting newer compilers supporting C++14. So if you want to simplify the code, keep the include guards and drop the pragma.

#pragma once is simpler then include guards. -- Olaf

Josh Juran

12:56 p.m.

On Nov 25, 2018, at 7:46 AM, Olaf van der Spek via Boost wrote:

...

On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost wrote:

...
since `#pragma once` is non-standard and not reliable, there's little

Who has a sane reproducible test case showing the claimed unreliability?

#pragma once is simpler then include guards.

I once thought the same, until I was informed it was non-standard by the founder of the Nitrogen C++ library. I found out for myself that it was unreliable, in the Metrowerks compiler I was using at the time. Josh

charleyb123

1:02 p.m.

On Sun, Nov 25, 2018 at 5:46 AM Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

...

On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost wrote:

...
since `#pragma once` is non-standard and not reliable, there's little

Who has a sane reproducible test case showing the claimed unreliability?

The '#pragma once' discussion occasionally comes up in the Qt community, and they repeatedly decide to not use it. It came up again last month, and here is a use case of claimed unreliability (from Thiago):

...

For example, I have ~/src as a bind-mount to ~/dev/src. That means ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h are actually the same file, but they aren't for the effects of #pragma once because the paths differ.

Another problem is qcompilerdetection.h, qprocessordetection.h, qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to break the include cycle. Ditto for qlist.h + qstringlist.h and qbytearraylist.h

Excerpt from: *- https://lists.qt-project.org/pipermail/development/2018-October/033733.html --charley

James E. King III

1:16 p.m.

On Sun, Nov 25, 2018 at 8:02 AM charleyb123 via Boost wrote:

...

On Sun, Nov 25, 2018 at 5:46 AM Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

...
On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost wrote:

...
since `#pragma once` is non-standard and not reliable, there's little

Who has a sane reproducible test case showing the claimed unreliability?

The '#pragma once' discussion occasionally comes up in the Qt community, and they repeatedly decide to not use it.

It came up again last month, and here is a use case of claimed unreliability (from Thiago):

...
For example, I have ~/src as a bind-mount to ~/dev/src. That means ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h are actually the same file, but they aren't for the effects of #pragma once because the paths differ.

Another problem is qcompilerdetection.h, qprocessordetection.h, qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to break the include cycle. Ditto for qlist.h + qstringlist.h and qbytearraylist.h

Excerpt from: *- https://lists.qt-project.org/pipermail/development/2018-October/033733.html

--charley

The include search path ordering for the compilation unit does not change during compilation. Either ~/src or ~/dev/src will be first in the search path, therefore #pragma once would work properly for that case. - Jim

charleyb123

1:20 p.m.

On Sun, Nov 25, 2018 at 6:17 AM James E. King III via Boost < boost@lists.boost.org> wrote:

...

On Sun, Nov 25, 2018 at 8:02 AM charleyb123 via Boost wrote:

...
On Sun, Nov 25, 2018 at 5:46 AM Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

...
On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost wrote:

...
since `#pragma once` is non-standard and not reliable, there's little

Who has a sane reproducible test case showing the claimed

unreliability?

...
...
The '#pragma once' discussion occasionally comes up in the Qt community, and they repeatedly decide to not use it.

It came up again last month, and here is a use case of claimed unreliability (from Thiago):

...
For example, I have ~/src as a bind-mount to ~/dev/src. That means ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h are actually the same file, but they aren't for the effects of #pragma once because the paths differ.

Another problem is qcompilerdetection.h, qprocessordetection.h, qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to break the include cycle. Ditto for qlist.h + qstringlist.h and qbytearraylist.h

Excerpt from: *-

https://lists.qt-project.org/pipermail/development/2018-October/033733.html

...
--charley

The include search path ordering for the compilation unit does not change during compilation. Either ~/src or ~/dev/src will be first in the search path, therefore #pragma once would work properly for that case.

- Jim

Agree, except "current-dir" will be searched first for all `#include ""`, which would override the include search path order. --charley

Peter Koch Larsen

24 Nov 24 Nov

10:25 a.m.

In my code, I use #pragma once on new stuff, mostly because of lazyness. That said, there can be esoteric environments where this does not work so for boost I agree that the oldfashioned include guard is better. But why not use a guid in that case? This is IMO a better solution, reducing the risk of having identical names. With include-guards I do not use pragma once. Why have both? I do not believe there will be any performance difference with newer compilers. Peter On Sat, Nov 24, 2018 at 12:36 AM Robert Ramey via Boost wrote:

...

In the safe numerics library my *.hpp files start with the following boiler plate:

#ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP

// MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif

...

I would like to replace all this in every file with just

#pragma once

according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9

this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray.

I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

mike.dev＠gmx.de

25 Nov 25 Nov

9:28 p.m.

...

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost

In the safe numerics library my *.hpp files start with the following boiler plate:

#ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP

// MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif

...

I would like to replace all this in every file with just

#pragma once

Whatever you do, there is zero reason to keep both - the include guards and #pragma once. We prefer #pragma once in our internal libraries and projects, simply for brevity and because it doesn't require one to come up with any consistent unique naming scheme that has to be maintained when the file is e.g. moved around. Also, if a TU does happen to include the (nominally) same header from two different locations for some wicket reason, there is a very high chance, that those headers have actually a different version and I welcome a compile-time error in that case which I don't get with include guards (unless they are versioned themselves). In any case: I still haven't seen a single case, where #pragma once doesn't work as expected, but I guess boost libraries are used in so many different environments, that you most likely will break someone somewhere if you remove the include guards and only rely on #pragma once, while removing #pragma once and retaining the include guards should be safe. Best Mike

2177

Age (days ago)

2179

Last active (days ago)

List overview

Download

10 comments

10 participants

participants (10)

Andrey Semashev
charleyb123
Emil Dotchevski
James E. King III
Josh Juran
mike.dev＠gmx.de
Olaf van der Spek
Peter Koch Larsen
Robert Ramey
Steven Watanabe