Thread (6 messages) read the whole thread 6 messages, 4 authors, 2020-06-20

Re: [PATCH] linux++, this: rename "struct notifier_block *this"

From: Alexey Dobriyan <hidden>
Date: 2020-06-20 07:57:39
Also in: lkml, netdev, netfilter-devel

On Fri, Jun 19, 2020 at 11:37:47AM -0700, Linus Torvalds wrote:
On Thu, Jun 18, 2020 at 2:06 PM Alexey Dobriyan [off-list ref] wrote:
quoted
Rename
        struct notifier_block *this
to
        struct notifier_block *nb

"nb" is arguably a better name for notifier block.
Maybe it's a better name. But it doesn't seem worth it.

Because C++ reserved words are entirely irrelevant.

We did this same dance almost three decades ago, and the fact is, C++
has other reserved words that make it all pointless.
The real problems are "class" and "new" indeed.
There is no way I will accept the renaming of various "new" variables.
I'm not sending "new".
We did it, it was bad, we undid it, and we now have a _lot_ more uses
of 'new' and 'old', and no, we're not changing it for a braindead
language that isn't relevant to the kernel.

The fact is, C++ chose bad identifiers to make reserved words.

If you want to build the kernel with C++, you'd be a lot better off just doing

   /* C++ braindamage */
   #define this __this
   #define new __new

and deal with that instead.
Can't do this because of placement new.
Because no, the 'new' renaming will never happen, and while 'this'
isn't nearly as common or relevant a name, once you have the same
issue with 'new', what's the point of trying to deal with 'this'?
I'm not sending "new".

There is stuff which can be merge without breaking source compatibility
and readability of C version:

	private		=> priv
	virtual		=> virt
	this		=> self (in some contexts)

and those which can not. I'm not sending the latter.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help