lkml.org 
[lkml]   [2021]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: #pragma once (was Re: incoming)
On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan <adobriyan@gmail.com> wrote:
> >
> > I want to sent treewide "#pragma once" conversion:
>
> Are there *any* advantages to it?
>
> It's non-standard,

It is effectively standard:
https://en.wikipedia.org/wiki/Pragma_once#Portability

and I'll spare UAPI headers from conversion.

> and the historical argument for it ("it can reduce
> compile times because the preprocessor doesn't open the file twice" is
> pure and utter hogwash. Any preprocessor worth its salt does the same
> thing for the standard and traditional #ifndef/#define guard sequence.
>
> Honestly, "#pragma once" was always a hack for bad preprocessors that
> weren't smart enough to just figure it out from the regular guarding
> macros.
>
> I can't imagine that any preprocessor that incompetent exists any
> more, and if i does, we sure shouldn't be using it.
>
> So #pragma once seems to have no actual advantages.

The advantage is removing busywork that is include guards.

There are rules and schemes about how to create guard macro.

Should it be prefixed by underscore?
Should it be prefixed by two underscores?
Should it be full path uppercased or just last path component?
Should the guard macro be lowercased?
Should it be changed when header is moved?
Should trailing #endif contain comment?
Should #define be just #define or "#define FOO 1"?

I've even seen advice (or an IDE doing that) that is should contain
timestamp of a header creation time to minimise collisions (implying
collisions could happen as could typos as could broken guards)

All this zoo of styles and made up mental work is completely avoided
by using #pragma once:

1) put #pragma once on the first line

or

2) put #pragma once on the second line after SPDX banner

and that's it.

No fuss, no filled up preprocessor hashtables, no implicit arguing
about styles. And way less LOC:

18092 files changed, 18883 insertions(+), 99841 deletions(-)

Now if old school header guard is necessary it can be used like in
good old times.

Nobody would miss include guards.

\
 
 \ /
  Last update: 2021-02-27 00:04    [W:0.083 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site