24

For example, is this any of the following

  • Bad practice
  • Unreadable
  • Inefficient (the call to this pointer)
  • Any other reason why it's bad to do this

.

class Person {

    public:
        string name;
        Person(string name) {
            this->name = name;
        }

};

P.S.

How about Person(string name) : name(name) { }

Oleksiy
  • 37,477
  • 22
  • 74
  • 122
  • What makes you think this would be inefficient? – Fred Foo Aug 04 '13 at 12:03
  • I don't know, maybe the extra overhead of 4 bytes for this pointer :/ That's why I'm asking – Oleksiy Aug 04 '13 at 12:04
  • 3
    None of the above. It's a known idiom. – Sergey Kalinichenko Aug 04 '13 at 12:04
  • @OleksiyDobrodum: the `this` is always there whether you state it explicitly or not. – Mat Aug 04 '13 at 12:06
  • Except the efficient point, this question is opinion-based. – Manu343726 Aug 04 '13 at 12:08
  • 1
    The overhead is in default constructing a string, and then assigning to it. Use the constructor initialization list, then you don't have to worry. – juanchopanza Aug 04 '13 at 12:12
  • There is other overhead: passing by value and not moving from it is very pointless. Either pass by `const&` so that at least you don't have to copy strings if the caller passes an existing one, or pass by value and move into the member so that there is only one copy in that case instead of the two that would be done here (assuming no copy elision, obviously). This is discussed to distraction elsewhere. – underscore_d Sep 21 '18 at 17:53

2 Answers2

20

No, I don't think this is a bad way to do so. Sometimes we even face the same method name or property name from different libraries. That's why we create namespace and class to resolve the naming conflict.

As long as it will not result in confusion, you should make it as simple as possible. Even though they use the same name. However, you shouldn't mix them, for example:

class Person {
public:
    Person(name) {
        this->name = name;
        name = clean(this->name);
        this->name = prefix + name;
    }

private:
    string name;
};

Keep it clean:

class Person {
public:
    Person(name) {
        name = clean(name);
        name = prefix + name;

        this->name = name;
    }

private:
    string name;
};
Yad Smood
  • 2,752
  • 2
  • 24
  • 37
4

The only issue(not a real issue) I can think of is that you can't distinguish member variable with local variable or function parameter. It's just coding style, it's nothing to do with efficiency, but when you talk about Unreadable, that's yes for me.

For me I normally name class member variable with trailing underscore. It helps code readability and makes it easier for maintenance.

class Person {    
    public:
        string name_;                // member variable with traling `_`
        string m_surname;            // some microsoft style declares member start with `m_`
        Person(const string& name)   // pass parameter by reference. 
        : name_(name)                // you know you are constructing member name_ with name variable
        {
        }

};
billz
  • 44,644
  • 9
  • 83
  • 100
  • 13
    I've seen all of these styles and I consider them very ugly and unnecessary. In API docs, it actually *helps* when constructor params and public member vars have the same name, as long as they actually denote the same thing. – Fred Foo Aug 04 '13 at 12:19
  • 4
    I don't think it's fair to say that you can't distinguish member variables from function parameters, as you obviously can. One is referred to with `this->varname` and one is referred to with `varname`. (Except of course in the case that there is no function parameter at all, and then there is no confusion.) – Resigned June 2023 Sep 10 '17 at 16:26
  • 2
    I love how when someone answers a subjective answer, 2 more people criticize the subjective answer with more subjective answers. If it is a known programming style, then people use it for a reason. I personally use the same parameter as member variable. It works just fine. – luminol Jul 21 '21 at 14:48
  • 1
    @luminol Sometimes this variety of response gives me a useful and representative sense of these subjective matters across members of programming communities. This is particularly useful when you're coming from different languages and you want to know what to expect. – Chris Mountford Jul 18 '23 at 00:48