From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Netdev <netdev@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
NetFilter <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH] linux++, this: rename "struct notifier_block *this"
Date: Sat, 20 Jun 2020 11:16:35 -0700 [thread overview]
Message-ID: <CAHk-=wjt=mTBqymWuRYeiXQxdEdf6si_it=Yzm7KR62ws0vknw@mail.gmail.com> (raw)
In-Reply-To: <20200620075732.GA468070@localhost.localdomain>
On Sat, Jun 20, 2020 at 12:57 AM Alexey Dobriyan <adobriyan@gmail.com> 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'?
Linus
prev parent reply other threads:[~2020-06-20 18:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 21:06 [PATCH] linux++, this: rename "struct notifier_block *this" Alexey Dobriyan
2020-06-19 7:46 ` Christoph Hellwig
2020-06-19 10:28 ` Jan Engelhardt
2020-06-19 18:37 ` Linus Torvalds
2020-06-20 7:57 ` Alexey Dobriyan
2020-06-20 18:16 ` Linus Torvalds [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wjt=mTBqymWuRYeiXQxdEdf6si_it=Yzm7KR62ws0vknw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).