7

Coming from Java, I am used to doing this:

void setColor(String color) {
    this.color = color;
}

However, I recently switched to C++, and I see a lot of this instead:

void setColor(string c) {
    color = c;
}

Why not this? Is this not recommended?

void setColor(string color) {
    this->color = color;
}
Jordi Castilla
  • 26,609
  • 8
  • 70
  • 109
user1529412
  • 3,616
  • 7
  • 26
  • 42
  • 4
    Its less typing. You don't have to use `this` in c++ but there is nothing stopping you from using it. – NathanOliver Oct 28 '15 at 16:11
  • 1
    @NathanOliver what he said. But also you don't need to use `this` if they aren't the same name. – 3kings Oct 28 '15 at 16:12
  • 2
    I see, I do like to use this for clarity reasons obviously. As long there is no penalty for this. – user1529412 Oct 28 '15 at 16:13
  • 1
    There's no `penalty` per se, but it's not the usual coding style C++ programmers use. Typically parameter names are usually made to be different in C++ from member names and local variables. – GreatAndPowerfulOz Oct 28 '15 at 16:15
  • 2
    @user1529412: There is a massive penalty in readability, and your coworkers keying your car for making such a mess of their code base. In general, asking about the "correct" syntax for writing getters/setters is a bit like asking whether it's better to cut off your leg with a chainsaw or an ax. Better to not cut off your leg (or write a getter/setter) at all. – Jerry Coffin Oct 28 '15 at 16:17
  • @Jerry, passing "String c" isn't very telling to me. – user1529412 Oct 28 '15 at 16:20
  • 1
    If your class has a member called `color` then just make the function take `color_` or switch it around and make the member variable end with a `_`. – NathanOliver Oct 28 '15 at 16:21
  • Possible duplicate of [When should you use the "this" keyword in C++?](http://stackoverflow.com/questions/2337540/when-should-you-use-the-this-keyword-in-c) – Sotirios Delimanolis Oct 28 '15 at 16:22
  • Good point. It should obviously be `Color c`. C++ should be written strongly typed, not stringly typed (Java probably should too, but I don't figure there's any real hope for Java being written well, so I'll ignore it there). – Jerry Coffin Oct 28 '15 at 16:25
  • @JerryCoffin: There is an entire chapter in Effective Java about preferring strong types over strings (Item 50: "Avoid strings where other types are more appropriate"). Something like `String color` is **not** good Java as much as `std::string color` would not be good C++. – Christian Hackl Oct 28 '15 at 16:35
  • @ChristianHackl: The fact that a book would bother mentioning something so obvious shows the degree to which Java is hopeless in the regard. IOW, of course it's a bad idea--but the fact that they have to advise against it indicates that it's common/widespread. – Jerry Coffin Oct 28 '15 at 16:39
  • @JerryCoffin: Many Java programmers are hopeless in this regard. Then again, many "C++ programmers" are hopeless as well when they still use `char*` and friends for strings in high-level code. That does not mean that a book should not mention the obvious :) – Christian Hackl Oct 28 '15 at 16:41
  • @Christian, I am java certified and used it for a long time, I totally agree with what you said, but there are things that are better in C++, for instance I find often that I have to use operator overloading and templates which are one of the examples that C++ is more suitable than Java. – user1529412 Oct 28 '15 at 18:57
  • @user1529412: As far as I am concerned, references and destructors are the killer features of C++. – Christian Hackl Oct 28 '15 at 19:05

2 Answers2

13

It's the exact same thing. In Java if you had named your parameter c instead of color, you would not have any shadowing and you could easily write

void setColor(String c) {
    color = c;
}

The this in Java (or C++ for that matter) is only needed to specify exactly which color you are referring to: the member variable or the local variable.

Emil Laine
  • 41,598
  • 9
  • 101
  • 157
NoseKnowsAll
  • 4,593
  • 2
  • 23
  • 44
1

There is no need to use this, because there is no conflict between local and member variable and no fields are hidden. Generally you don't want this conflict to happen at all by not having same variable as an constructor parameter and also as local variable (despite so many books teach you exactly this). I find this is much more smooth(and also more readable even if you don't have background from particular language):

private String localColor;
void setColor(String color) {
localColor = color;
}
The Law
  • 344
  • 3
  • 20