Thread (6 messages) flat view 6 messages, 4 authors, 2020-06-20

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2020-06-20 18:18:08
Also in: linux-arch, lkml, netfilter-devel

On Sat, Jun 20, 2020 at 12:57 AM Alexey Dobriyan [off-list ref] wrote:
quoted
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.
Can you explain?
quoted
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".
My point about 'new' is that

 (a) there's a lot more 'new' than 'this'

 (b) without dealing with 'new', dealing with 'this' is pointless

So why bother? Without some kind of pre-processing phase to make our C
code palatable to a C++ parser, it will never work.

And if you _do_ have a pre-processing phase (which might be a #define,
but might also be a completely separate pass with some special tool),
converting 'this' in the kernel sources isn't useful anyway, because
you could just do it in the pre-processing phase instead.

See? THAT is why I'm harping on 'new'. Not because you sent me a patch
to deal with 'new', but because such a patch will never be accepted,
and without that patch the pain from 'this' seems entirely irrelevant.

What's your plan for 'new'? And why doesn't that plan then work for 'this'?

              Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help