All of lore.kernel.org
 help / color / mirror / Atom feed
* #pragma once (was Re: incoming)
@ 2021-02-26 20:17 Alexey Dobriyan
  2021-02-26 21:53 ` Linus Torvalds
  0 siblings, 1 reply; 5+ messages in thread
From: Alexey Dobriyan @ 2021-02-26 20:17 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel, akpm

Linus wrote:

> I'm hoping to just do -rc1 this weekend after all - despite my late
> start due to loss of power for several days.
> 
> I'll allow late stragglers with good reason through, but the fewer of
> those there are, the better, of course.

I want to sent treewide "#pragma once" conversion:

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

ideally it is done as 1 commit avoiding my death by thousand cuts of
going through all of maintainers.

There may be a compile failure or two but the list of exceptions is
stable.

Opinions? :-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: #pragma once (was Re: incoming)
  2021-02-26 20:17 #pragma once (was Re: incoming) Alexey Dobriyan
@ 2021-02-26 21:53 ` Linus Torvalds
  2021-02-26 23:02   ` Alexey Dobriyan
  0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2021-02-26 21:53 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: Linux Kernel Mailing List, Andrew Morton

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, 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.

               Linus

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: #pragma once (was Re: incoming)
  2021-02-26 21:53 ` Linus Torvalds
@ 2021-02-26 23:02   ` Alexey Dobriyan
  2021-03-01 16:52     ` David Laight
  2021-03-01 20:29     ` Al Viro
  0 siblings, 2 replies; 5+ messages in thread
From: Alexey Dobriyan @ 2021-02-26 23:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Andrew Morton

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: #pragma once (was Re: incoming)
  2021-02-26 23:02   ` Alexey Dobriyan
@ 2021-03-01 16:52     ` David Laight
  2021-03-01 20:29     ` Al Viro
  1 sibling, 0 replies; 5+ messages in thread
From: David Laight @ 2021-03-01 16:52 UTC (permalink / raw)
  To: 'Alexey Dobriyan', Linus Torvalds
  Cc: Linux Kernel Mailing List, Andrew Morton

From: Alexey Dobriyan <adobriyan@gmail.com>
> Sent: 26 February 2021 23:02
> 
> 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

At the top of the page....

In the C and C++ programming languages, pragma once is a non-standard but widely supported

So non-standard :-)

And #pragma is ugly...

There are also times when an include guard has to be set in order to stop
a problematic inner file being included.
Perhaps only during hacking, but it is useful.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: #pragma once (was Re: incoming)
  2021-02-26 23:02   ` Alexey Dobriyan
  2021-03-01 16:52     ` David Laight
@ 2021-03-01 20:29     ` Al Viro
  1 sibling, 0 replies; 5+ messages in thread
From: Al Viro @ 2021-03-01 20:29 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: Linus Torvalds, Linux Kernel Mailing List, Andrew Morton

On Sat, Feb 27, 2021 at 02:02:21AM +0300, Alexey Dobriyan wrote:

> 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"?

Who cares?  To all of the above, really.

> 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)

Ever seen that in the tree?  Where, if so?

> 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.

Care to provide some stats on the amount of those macros encountered
on build, along with the total amount of defines parsed and hashed?
It's noise.

And what is "implicit arguing", BTW?  I'm yet to see any fights
along those lines - you are the first one to bring that up, AFAICS.
Maybe I'd simply been lucky until now, of course, but...

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-03-02  7:09 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-26 20:17 #pragma once (was Re: incoming) Alexey Dobriyan
2021-02-26 21:53 ` Linus Torvalds
2021-02-26 23:02   ` Alexey Dobriyan
2021-03-01 16:52     ` David Laight
2021-03-01 20:29     ` Al Viro

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.