Code style: this->m_member vs just m_member

[paulgessinger]

The eternal struggle.

I notices @stephenswat recently added some code which uses the style this->m_member to access member variables and methods. I don't think we use this anywhere else, and rely on the prefix m_X to mark members relative to local variables. In a few cases we do use it to disambiguate.

Do we want to include this in our code guidelines in some form? Encourage / discourage it?

This doesn't have to be absolutely consistent, it's just something I thought we should think about.

[HadrienG2]

Since we have lots and lots of m_xyz around, I'd just use m_xyz everywhere for consistency and minimal migration effort.

[stephenswat]

So the issue here is that using the variable without de-referencing this is not always possible! As I understand it, you can use the this-less form only for members of the class itself, not members of a parent class.

That is, unless I've really misunderstood something.

[HadrienG2]

I'm afraid godbolt seems to disagree with you on this matter.

[HadrienG2]

This bit from cppreference is interesting though:

Within the body of a non-static member function of X, any id-expression E (e.g. an identifier) that resolves to a non-type non-static member of X or of a base class of X, is transformed to a member access expression (*this).E (unless it's already a part of a member access expression). This does not occur in template definition context, so a name may have to be prefixed with this-> explicitly to become dependent.

To translate the standardese into a human-readable form, C++ template parsing is hopelessly broken and because of that you may need seemingly superfluous this qualifiers in certain (obviously unspecified, otherwise it would spoil all the fun of discovering it yourself) template contexts.

[HadrienG2]

But at least the basic stuff seems to work as expected.

[HadrienG2]

It seems you need a templated base class and a templated child class to make it fail.

(And in case you're wondering why C++ templates are such a mess, a significant fraction of the answer is "unconstrained specialization". When the compiler has zero ability to even tell what members a struct template will have before instantiating it, it isn't so surprising that said compiler won't behave sanely in the presence of code that refers to struct templates with unspecified parameters.)

[paulgessinger]

In that case I guess it would make the most sense to use explicit this in these cases where it's needed.