5

I was wondering if this-> should be used both:

void SomeClass::someFunc(int powder)
{
     this->powder = powder;
}

//and
void SomeClass::someFunc(bool enabled)
{
     this->isEnabled = enabled;
}

I'm wondering if the latter is necessary to be proper or if isEnabled = enabled would suffice.

Thanks

jmasterx
  • 52,639
  • 96
  • 311
  • 557
  • 2
    Why don't you just go ahead and try it? .. this-> is only needed when there's ambiguity (e.g. the first case, where the parameter takes precedence, but there are other situations, like some obscure template cases). – falstro Dec 20 '10 at 15:50
  • I know what works and what doesn't I just mean which one is proper OOP – jmasterx Dec 20 '10 at 15:51
  • 9
    Proper OOP has no comment on the subject. Much like brace location it is a matter of coding style. – stonemetal Dec 20 '10 at 15:52
  • It's the same discussion as 'this.' in java, which usually ends up in "it's a matter of style, try to adopt the style of the project you're working on". – falstro Dec 20 '10 at 15:53
  • 1
    It is commonly used when you like IntelliSense (aka auto-completion). – Hans Passant Dec 20 '10 at 15:59
  • Don't uglify your code, if "this" is not required for disambiguation or lookup, don't put it explicitly. – Gene Bushuyev Dec 20 '10 at 16:12
  • @GeneBushuyev Don't obfuscate your code. If `this` may possibly be specified, use it. The only exception here would be static variables (particularly those that like to move back and forth between static and dynamic for some reason) PS - I agree with stonemetal about style. Most especially when you're in a really bad mood, it's great to be sure all variables prefixed with `m_` always have `this->` in front of them. If a coding standard is designed to be ugly don't stand in its way. –  Apr 02 '14 at 17:34

4 Answers4

4
this->

is needed when using the member directly would be ambiguous. This could happen with template code.

Consider this:

#include <iostream>

template <class T>
class Foo
{
   public:
      Foo() {}
   protected:
      void testing() { std::cout << ":D" << std::endl; }
};

template <class T>
class Bar : public Foo<T>
{
   public:
      void subtest() { testing(); }
};

int main()
{
   Bar<int> bar;
   bar.subtest();
}

This will fail since calling testing() is dependent on a template parameter. To say that you mean the function you will have to do this->testing(); or Foo<T>::testing();

Error message:

temp.cpp: In member function ‘void Bar<T>::subtest()’:
temp.cpp:16:32: error: there are no arguments to ‘testing’ that depend on a template parameter, so a declaration of ‘testing’ must be available [-fpermissive]
temp.cpp:16:32: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
Maister
  • 4,978
  • 1
  • 31
  • 34
  • 1
    This is not because of the ambiguity, but because the lookup of dependent names is delayed to the point of instantiation. – Gene Bushuyev Dec 20 '10 at 16:17
3

this is just a pointer to the object itself. It is made for readability, so that you know you're referencing to the object functions or variables, not something within the function.

I don't think there's any other good reason for it other than readability :-)

It's also good if you want to avoid ambiguous reference. Assume you have a global variable and a variable within the function that has the same name, then this-> would reference to the global variable.

Jón Trausti Arason
  • 4,548
  • 1
  • 39
  • 46
1

I think in C++ you leave out the this->, however it's probably personal preference. With or without the code still does the same thing.

Tony The Lion
  • 61,704
  • 67
  • 242
  • 415
0

I tend to follow this simple rule of thumbs:

  • Attributes: no this, if it's not a parameter of the method, then it's obviously an attribute of the class (and I tend to rely on naming convention anyway to distinguish them)
  • Methods: this->, to distinguish class methods from free-standing functions

The second also brings consistency, since it might be necessary in templated code (and I wrote a lot of it, especially in my pet projects).

The rationale behind this is simple: write as much as necessary to be explicit (ie make the life of your reader easier), but not a stitch more (this would be clutter), which follows Antoine de Saint-Exupery's:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722