51

Possible Duplicates:
Is excessive use of this in C++ a code smell

Years ago, I got in the habit of using this-> when accessing member variables. I knew it wasn't strictly necessary, but I thought it was more clear.

Then, at some point, I started to prefer a more minimalistic style and stopped this practice...

Recently I was asked by one of my more junior peers whether I thought it was a good idea and I found that I didn't really have a good answer for my preference... Is this really a wholly stylistic choice or are there real reasons why not prefixing this-> on member variable accesses is better?

Community
  • 1
  • 1
dicroce
  • 45,396
  • 28
  • 101
  • 140
  • Dupe http://stackoverflow.com/questions/1128837/using-this-in-front-of-member-variables-in-c and http://stackoverflow.com/questions/1057425/is-excessive-use-of-this-in-c-a-code-smell –  Feb 25 '10 at 21:00
  • See also "Is there any reason to use `this->`?": http://stackoverflow.com/questions/577243/is-there-any-reason-to-use-this – sth Feb 25 '10 at 21:04

6 Answers6

46

While this is a totally subjective question, I think the general C++ community prefers not to have this->. Its cluttering, and entirely not needed.

Some people use it to differentiate between member variables and parameters. A much more common practice is to just prefix your member variables with something, like a single underscore or an m, or m_, etc.

That is much easier to read, in my opinion. If you need this-> to differentiate between variables, you're doing it wrong. Either change the parameter name (from x to newX) or have a member variable naming convention.

Consistency is preferred, so instead of forcing this-> on yourself for the few cases you need to differentiate (note in initializer lists this is completely well-defined: x(x), where the member x is initialized by the parameter x), just get better variable names.

This leaves the only time I use this: when I actually need the address of the instance, for whatever reason.

GManNickG
  • 494,350
  • 52
  • 494
  • 543
  • 4
    Clearly "m_" is sort of a love-it-or-hate-it thing. I love it myself. Having p_Thing, l_Thing and m_Thing referenced in the same method is not unusual where Thing is simply the logical name for all three. It's common enough to have at least two clash (getters and setters, for instance) that it makes sense to me to just apply the convention all the time. –  Feb 25 '10 at 21:14
  • 1
    Do you still use the `m` prefix? – StackedCrooked Oct 11 '14 at 00:25
  • @StackedCrooked: I don't code much C++ anymore, so no. :) If I were to, it would be to my company's style guide, which is to place an underscore at the end of the name. My personal code, I would probably wind up using the same style out of habit. – GManNickG Oct 11 '14 at 07:23
  • 3
    Definitely love-it-or-hate-it-but-use-whatever-coding-style-your-company-uses. :P Personally, I hate it. It's ugly and I'd say most of the time the same criticism applies to it as to `this->`. Meh. +1 anyway. ;) – Xupicor Jul 25 '15 at 11:10
  • The PHP devs should have read this before implementing their OO features... – Déjà vu Sep 19 '16 at 18:49
9

I can only recall doing it with

delete this;
Tim
  • 20,184
  • 24
  • 117
  • 214
8

Personally I never use this, except:

  • when I need to pass 'this' as an argument to a method of another class
  • in the implementation of the assignment operator
Patrick
  • 23,217
  • 12
  • 67
  • 130
6

When there is an ambiguity between, say, a function parameter and an instance variable.

Of course such ambiguity should be avoided! It might be preferable to change the function parameter name instead of incurring overhead (i.e. prefixes) for all access to instance parameters though...

jldupont
  • 93,734
  • 56
  • 203
  • 318
  • 1
    Wouldn't creating such an ambiguity be bad style? – Heath Hunnicutt Feb 25 '10 at 20:57
  • 3
    Use a naming convention that prevents such ambiguity, e.g. precede all data members with m_. – Patrick Feb 25 '10 at 20:58
  • 21
    m_ is horrible, as is any other prefix. – Finglas Feb 25 '10 at 20:59
  • 13
    Personally I think things like "precede all data members with m_" just causes pointless noise, just like hungarian notation. It fixes this "problem", but seems silly to me. – Herms Feb 25 '10 at 20:59
  • 7
    Why prefer a naming convention to a language feature? – Jeff Sternal Feb 25 '10 at 21:00
  • 3
    @Patrick: Why? Do you also avoid namespaces and instead prefix all your names with some kind of pseudo-namespace, as in `boost_shared_ptr` instead of `boost::shared_ptr`? The nice thing about `this->` is that it can be omitted when it's unnecessary, yielding cleaner code. You can't omit a hardcoded `m_` prefix. – jalf Feb 25 '10 at 21:00
  • 5
    No I don't avoid namespaces, I don't prefix all names to prevent namespaces, I only use m_ for data members. The point is that you want clear, readable code. If you omit prefixes like m_ and can still keep clear code, fine, then don't use it. Personally, I find my code clearer if I prefix data members with m_. – Patrick Feb 25 '10 at 21:05
3

I like to use it for clarification, as when accessing members that were inherited. It reminds the reader where the variable came from if you don't have a naming convention that conveys that information.

You must use the this pointer when:

  • Returning the current object.
  • Setting up relations between objects (passing this into a constructor or setter)
  • Checking for self reference: this != argPtr
thebretness
  • 632
  • 3
  • 13
2

For me, it depends. If it is a short function or variable, I just type it in (e.g. mCount). Most of the time, however, I use very descriptive member variable and function names (e.g. mExclusivelyLockedDigitalIOList ). In those instances, I tend to use the this pointer to have Visual Studio's IntelliSense finish my typing for me. Saves on keystrokes and spelling mistakes.

bsruth
  • 5,372
  • 6
  • 35
  • 44