As a matter of curiosity, I'm wondering to what extent those of you who program in C++ make use of the "this" class instance pointer; whether it be actually using "this" or using a macro that substitutes for "this" (such as having a macro "self" which allows you to go "self->blah" instead of "this->blah"). Do you use it every single time you use a class's members? Do you try to never use it and just let the compiler figure it out for you? Is there some other particular guideline or style you follow for when to use it?

You see, at the moment I'm somewhat paranoid about the idea of having a situation where the compiler/program might confuse a class's variable for some other (local or global) and create bugs or other issues, so I've been explicitly using 'this' any time I handle a class's member so that I can personally know that there won't be any confusion. I.e,

Other* Example::method( int stuff )
{
  this->thing = stuff;
  this->thing2 = this->more_stuff( this->thing );
  return this->something( stuff );
}

What is nagging at my mind though is that doing that (above) seems to be defeating the purpose of being able to do this (below) instead:

Other* Example::method( int stuff )
{
  thing = stuff;
  thing2 = more_stuff( thing );
  return something( stuff );
}

Thoughts?

I rarely use "this". Usually only in member functions like operator=, operator==, etc.

For starters, my instance variables follow a naming convention that makes it basically impossible to confuse them with local variables and parameters. If class A has an instance variable "foo", it will actually be written "foo_". Some people write "m_foo". Then, if I have a parameter foo, I simply write: foo_ = foo

If I feel that something is confusing, I will use 'this->foo_' to make it extremely clear that I'm referring to the instance variable. This is relatively rare, because the naming convention prevents this. If I can't use the naming convention (for example, working on a larger project with a different convention) then I use 'this' to disambiguate.

I never use a macro to turn 'self' into 'this'. I think that's dangerous.
I certainly don't use it every time I access a class's members, although I've gotten used to having to in languages like Python and Lua.
I am not a fan of letting "the compiler figure it out", because usually that means that humans have to figure it out and I prefer clarity.



Basically, if you follow sane naming conventions, your instance variables will not be confused with globals, and only rarely with parameters or locals; if your functions are so big that you can't see immediately that a parameter or local has the same name, you're doing something wrong with your function design.

Altering my naming conventions is a work in progress; I'm still trying to figure out what I'm comfortable with and what makes sense to me. I think I'll give the underscore thing a try in a moment using a copy of a file, to see how it looks in practice.


You'll have to explain this one to me in further detail, as I'm not understanding what danger there is in using such a macro. All instances of "self" become "this" and the code works as intended.


If you're going to decry "insane" naming conventions, it would be helpful to include some sort of reference to what you consider to be the "sane" naming conventions. A book, a website, etc.

You might find my C++CodingStandards useful.

It's the principle of least surprise. Surprise is dangerous because it's confusing. Magic is dangerous because it's confusing. Confusing things are bad because they make people make mistakes if they don't understand, or they generally slow things down as people have to figure out what is what.

Programmers in C++ expect to see "this", not "self". Programmers in Python expect to see "self", not "this". Conventions exist to facilitate communication. If we both spell words the same way, we don't have to wayste tym figyuring out what was meante bye the other personn. (Just look at older English spelling, before normalization, and see how long it takes you to work through the words compared to the exact same text written with normalized modern spelling.) Introducing any confusion, beyond what is absolutely necessary due to complexity of the problem being solved, is simply inviting people to make mistakes because they think they understand something but actually don't.

It might be hard to appreciate a lot of this, I suppose, if you haven't written code on a team before.


I didn't realize that I decried any insane naming conventions. However, what defines sanity is really quite easy in this case. Things are sane if they are consistent, unambiguous (without being overly awkward), and unsurprising. I didn't look at Tyche's material much but I imagine it's sane.

Different people have different conventions, of course. Java programmers use more camelCase, whereas C programmers tend to prefer_underscores. In the end of the day, a lot of that is preference, as long as the whole thing is consistent.

I think that sums up my opinion on the subject.

"DWH"? "W" = ?

Thanks.


Fair enough.


I see.

Wayne

If you flip W upside down it could be DMH.

I haven't found a compelling reason to ever use macros to redefine/alias keywords. It makes it extremely unclear that you have done this unless someone specifically is reading your headers with little gain. Almost every long time programmer who uses a lot of different languages writes code in those different languages differently and with the languages standardized style. Including this or self, spacing, and braces notation. Consistency shouldn't be undervalued. At some people in the future almost all programmer benefit from it.

(And in a lot of the language specific forums you'll have people poke at you for this type of thing any time you post. With good reason.)

Besides, for what it's worth, not only is the consistency important, but also I find that seeing code in a particular language's style with its idiosyncrasies makes it easier to context-switch between languages, as you have more cues to which language you're in by seeing the general style & keywords used.

I have a naming convention (trailing underscore) that makes this noise in most instances.

The only places I can think of that I use it are to pass a pointer to this to another function or object (and even then, that's frequently spelled shared_from_this() these days), or to refer to a member of a base class whose name is dependant.

Yes.