[lkml]   [2020]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] linux++, this: rename "struct notifier_block *this"
On Sat, Jun 20, 2020 at 12:57 AM Alexey Dobriyan <> wrote:
> > 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?

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


 \ /
  Last update: 2020-06-20 20:18    [W:0.086 / U:4.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site