4

Possible Duplicates:
Is there any reason to use this->
When should this-> be used?
When should I make explicit use of the this pointer?

When working with pointers to classes, I like to add a this-> in front of variables in a class to make it clearer that the variable I'm talking about is in the current class, as opposed to temporary variables, etc. So my lines would be something like

if(this->thing > other->thing)
    this->doFoo();

Instead of

if(thing > other->thing)
    doFoo();

Is it okay to add the superfluous this, or would that degrade code readability?

Community
  • 1
  • 1
wrongusername
  • 18,564
  • 40
  • 130
  • 214
  • 9
    This is really a judgment call unless it's to disambiguate. I think most C++ programmers omit the `this->`. – templatetypedef Jan 20 '11 at 06:55
  • 1
    Many duplicates: http://stackoverflow.com/questions/577243/is-there-any-reason-to-use-this http://stackoverflow.com/questions/993352/when-should-i-make-explicit-use-of-the-this-pointer http://stackoverflow.com/questions/4491234/when-should-this-be-used – CB Bailey Jan 20 '11 at 07:55

7 Answers7

4

That depends on your coding style, however many people would use

_myVariable
m_myVariable
myVariable_

To differentiate member variables from the other.

But the most important thing is to just be consistent

kshahar
  • 10,423
  • 9
  • 49
  • 73
4

Consistency consistency consistency.

I conisder the this-> prefix a valid coding style if you use it throughout your entire project everywhere a member is accessed.

I prefer using a signifying prefix for members, e.g. m_. I feel it is less cutter and less tag soup than the explicit this->:

(alpha-this->gamma > this->alpha-gamma)

vs.

(alpha-m_gamma > m_alpha-gamma)

(The dotNetties have labeled m_ outdated - I use it on small C# projects out of spite. but anyway, any other distinct prefix would do, too.)

I've seen it used often to help intellisense get in gear, or to specifically filter members - which is ok, though leaving it in for that reason is questionable, especially if not used consistently.

peterchen
  • 40,917
  • 20
  • 104
  • 186
  • Most of us "dotNetties" still prefix private members with an underscore, even if we only do it secretly. :-) Microsoft does it themselves throughout the framework. It's so much easier and cleaner than remembering to prepend everything with `this.`, and it's almost necessary in VB.NET where you don't have case-sensitive identifiers (which I happen to think is a better idea). Anyway, +1 for consistency. – Cody Gray - on strike Jan 20 '11 at 07:12
  • I now do that too for the few "serious" (i.e. seen-by-others) C# tools I work on. If it's just a scratch program it's one of the very few things I find hard when switching between C++ and C#. – peterchen Jan 20 '11 at 07:19
2

This is a style question, so answers will be subjective. Similarly, a lot of people I've worked with like to prefix member variables with m_ to make it clear that it's a member. (m_foo would be like your this->foo.) Then I'm sure there are people who feel this is a crime against the universe. YMMV. Use what works for you and anyone you might be working with.

One advantage (or disadvantage, depending on who you ask) to this-> is that you can have a variable with the same name that can be both a member and something locally scoped like a parameter or local variable, eg.:

foo bar;

void f(foo bar)
{
   this->bar = bar;
}
asveikau
  • 39,039
  • 2
  • 53
  • 68
  • 4
    I'm in the "crime against the universe" camp :-) I think I'd rather use `this->` than encode category information into the name. And I hate things like `szBuffer`. Oh yeah, and get off my lawn :-) – paxdiablo Jan 20 '11 at 06:58
  • 2
    I'd just like to apologize for the ongoing crimes I commit against the universe. I strongly prefer prefixing member variables with `m_` or just an underscore. – Cody Gray - on strike Jan 20 '11 at 07:06
  • 2
    I like the responses. Something tells me the universe will "keep on universing" no matter what we name things, but I was trying to illustrate that people feel strongly about stylistic stuff. :-) – asveikau Jan 20 '11 at 07:10
  • +1 for the Gran Torino-reference. – Andreas Ågren Jan 20 '11 at 07:39
2

As already noted this is, mostly, a matter of style.

Personally I do not use it for the data-members (I use the m prefix alternative), however I do use it for functions:

  • for consistency with templated code, where this might be necessary to defer lookup
  • for clarity, in order to distinguish at a glance whether it's a method of the class (possibly a base class) or a free-standing function

I think that, since you definitely don't want to trudge through levels of base class when reading up some code, the this-> clarification makes it much easier for the reader. And it's only 6 more characters to type.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
  • 6 more characters a line keep Carpal Tunnel nearby! :) – Mutoh Jul 11 '14 at 21:04
  • Do you still use the `m` prefix for member variables? – StackedCrooked Oct 11 '14 at 00:20
  • @StackedCrooked: At work I have to use `_`; for personal projects I have used `m` (or sometimes slipped into using `_` by habit), though it has been a while since I last programmed in C++ at home. Rust has all my attention these days. – Matthieu M. Oct 11 '14 at 12:28
1

I like this pattern too, but I like it more in managed code where it's "this." - the arrow operator does feel a bit noisier, but still it makes it very clear when you're referring to instance-level stuff.

Austin Lamb
  • 3,116
  • 1
  • 22
  • 13
1

of course you can do it, besides, the compiler would add it for you.

outsky
  • 11
  • 1
-1

Normally you use this notation, when your method arguments and the member variables have the same name. (to differentiate the method argument with the member variable)

Say for e.g,

void CMYClass::fun1(int sameName)
{
...
this->sameName = sameName;
}

Otherwise, it's just a matter of taste...

AntoineB
  • 4,535
  • 5
  • 28
  • 61
liaK
  • 11,422
  • 11
  • 48
  • 73