Guidence on #pragma once

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Guidence on #pragma once

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
On Fri, Nov 23, 2018 at 3:36 PM Robert Ramey via Boost <
[hidden email]> 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. :)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Nov 24, 2018 at 2:36 AM Robert Ramey via Boost
<[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
On Nov 25, 2018, at 7:46 AM, Olaf van der Spek via Boost <[hidden email]> wrote:

> On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost
> <[hidden email]> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Nov 25, 2018 at 5:46 AM Olaf van der Spek via Boost <
[hidden email]> wrote:

> On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost
> <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
On Sun, Nov 25, 2018 at 8:02 AM charleyb123 via Boost
<[hidden email]> wrote:

>
> On Sun, Nov 25, 2018 at 5:46 AM Olaf van der Spek via Boost <
> [hidden email]> wrote:
>
> > On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost
> > <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
On Sun, Nov 25, 2018 at 6:17 AM James E. King III via Boost <
[hidden email]> wrote:

> On Sun, Nov 25, 2018 at 8:02 AM charleyb123 via Boost
> <[hidden email]> wrote:
> >
> > On Sun, Nov 25, 2018 at 5:46 AM Olaf van der Spek via Boost <
> > [hidden email]> wrote:
> >
> > > On Sat, Nov 24, 2018 at 2:01 AM Andrey Semashev via Boost
> > > <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Guidence on #pragma once

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> 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


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