views:

393

answers:

3

class C {
  T a;
public:
  C(T a): a(a) {;}
};

Is it legal?

+7  A: 

Yes it is legal and works on all platforms. It will correctly initialize your member variable a, to the passed in value a.

It is considered by some more clean to name them differently though, but not all. I personally actually use it a lot :)

Initialization lists with the same variable name works because the syntax of an initialization item in an initialization list is as follows:

<member>(<value>)

You can verify what I wrote above by creating a simple program that does this: (It will not compile)

class  A
{

   A(int a)
   : a(5)//<--- try to initialize a non member variable to 5
   {
   }
};

You will get a compiling error something like: A does not have a field named 'a'.


On a side note:

One reason why you may not want to use the same member name as parameter name is that you would be more prone to the following:

class  A
{

   A(int myVarriable)
   : myVariable(myVariable)//<--- Bug, there was a typo in the parameter name, myVariable will never be initialized properly
   {
   }
   int myVariable;
};


On a side note(2):

One reason why you may want to use the same member name as parameter name is that you would be less prone to the following:

class  A
{

   A(int myVariable_)
   {
     //<-- do something with _myVariable, oops _myVariable wasn't initialized yet
     ...
     _myVariable = myVariable_;
   }
   int _myVariable;
};

This could also happen with large initialization lists and you use _myVariable before initializing it in the initialization list.

Brian R. Bondy
It's a matter of taste. I prefer to give identical names to identical thing. That's why I use namespaces widely.
Sergey Skoblikov
Very often for private fields you will find naming like "a_" or "_a".
Marcin Gil
Member variables are often m_a or _a. Scoped variables are often a_.
Brian R. Bondy
Good to know. Thanks.
Ferruccio
I've recently switched to using this technique too (and disambiguating with this-> in method bodies). It's my preferred way in C#, and coming back to C++ I've ditched my old practice of using the m_ prefix for member variables. Much nicer now (YMMV)
Phil Nash
about side note one: compiler will tell me about non-used parameter.
Sergey Skoblikov
sometimes in projects warnings get lost though because of the level of warning set or because of third party includes that you can't fix.
Brian R. Bondy
I always set maximum warning level. To deal with misbehaving third party headers one can use '#pragama warning' with 'suppress' option or 'disable' and 'default' options. It's for Visual C++.
Sergey Skoblikov
+4  A: 

Legal: yes, as explained by Brian, compiler knows the name to expect in the initializer list must be a member (or a base class), not anything else.

Good style: most likely not - for a lot of programmers (including you, it seems) the result is not obvious. Using a different name for the parameter will keep the code legal and make it a good style at the same time.

I would prefer writing some of:

class C {
  T a_;
public:
  C(T a): a_(a) {}
};


class C {
 T a;
 public:
 C(T value): a(value) {}
};
Suma
No, for me result is obvious. if a(a) construct is legal then it definitely means that those 'a' are different. I just wasn't sure is it really legal in C++.
Sergey Skoblikov
You need to be very careful about using identifiers with leading underscores, to avoid clashes with the implementation.You're actually OK when it's followed by a lowercase char, as here, but it's widely considered best to avoid them altogether. See question 228783 for more.
tragomaskhalos
It is a matter of preference, there are benefits both ways.
Brian R. Bondy
+2  A: 

if the formal parameter and the member is named same then beware of using this pointer inside constructor to use the member variable

class C {
  T a;
public:
  C(T a): a(a) {
this->a.sort ;//correct
a.sort();//will not affect the actual member variable
}
};
yesraaj
Hmm...that seems like an excellent reason to name them differently. Good point.
Onorio Catenacci