From: Ruslan Kabatsayev via Gdb-patches <gdb-patches@sourceware.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: Coding standards proposal, usage of "this"
Date: Wed, 18 Aug 2021 14:43:00 +0300 [thread overview]
Message-ID: <CAHEcG97WhuRDj+ghVLaYRXo0DVOg7ihh4Vx5e4ny6Uf5Hmz4Eg@mail.gmail.com> (raw)
In-Reply-To: <e86d9248-74f0-de5d-e490-b1aacd9062cb@polymtl.ca>
On Mon, 16 Aug 2021 at 20:01, Simon Marchi via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
> >> - Use `this` when referring to a method of the current class.
> >> Rationale: without `this, it's not clear that you are referring to a
> >> method of the current class, versus a free function.
> >
> > I'm not really a fan of this, and I am also not aware of other
> > projects using such a style. Since this makes calling member functions
> > more verbose/uglier than calling free functions, this would also
> > discourage member functions. Is there a need to distinguish these?
>
> There's no *need*, of course. It's just based on my experience, I
> remember seeing some function calls, wondering how it could even work
> with the passed arguments. And then I realized it was a method call,
> where `this` is passed implicitly.
>
> Do you think it would discourage adding member functions, in opposition
> to adding free functions? Or just leaving the code in-line, leading to
> bigger methods?
This will prevent the "prefer nonmember, nonfriends" mantra from
working. Suppose you made a free function (so as to prevent accidental
coupling to the private state of your class), and later it happens to
need access to the state. This function is then turned into a
(possibly const) method. And now... you have to alter all the callers
to prefix the calls with `this->`, even though it's syntactically
useless. Moreover, it may be easy to miss some, so unless there's a
static analyzer checking for this rule, this leads to inconsistency.
>
> Simon
next prev parent reply other threads:[~2021-08-18 11:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 14:26 Simon Marchi via Gdb-patches
2021-08-13 14:46 ` Paul Koning via Gdb-patches
2021-08-13 14:51 ` Simon Marchi via Gdb-patches
2021-08-13 14:47 ` Andrew Burgess
2021-08-15 13:34 ` Lancelot SIX via Gdb-patches
2021-08-16 16:40 ` Christian Biesinger via Gdb-patches
2021-08-16 16:59 ` Simon Marchi via Gdb-patches
2021-08-18 11:43 ` Ruslan Kabatsayev via Gdb-patches [this message]
2021-08-16 17:06 ` John Baldwin
2021-08-16 17:11 ` Simon Marchi via Gdb-patches
2021-08-16 17:23 ` Luis Machado via Gdb-patches
2021-08-16 17:31 ` Simon Marchi via Gdb-patches
2021-08-17 10:01 ` Andrew Burgess
2021-08-16 17:28 ` John Baldwin
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=CAHEcG97WhuRDj+ghVLaYRXo0DVOg7ihh4Vx5e4ny6Uf5Hmz4Eg@mail.gmail.com \
--to=gdb-patches@sourceware.org \
--cc=b7.10110111@gmail.com \
--cc=simon.marchi@polymtl.ca \
/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