Is this ambiguous or is it perfectly fine?

Question

Is this code ambiguous or is it perfectly fine (approved by standards/has consistent behavior for any compilers in existence)?

struct SCustomData {
    int nCode;
    int nSum;
    int nIndex;
    SCustomData(int nCode, int nSum, int nIndex)
        : nCode(nCode)
        , nSum(nSum)
        , nIndex(nIndex)
    {}
};

edit:
yes, I am referring to the fact that the member variables have the same name with formal parameters of the constructor.

Answer 1

Your example is unambiguous (to me), but it's not good practise, because it can quickly become as ambiguous as hell.

It's a long while since I've written any C++ in anger, so I'm guessing what the following will do.
Do you KNOW what it will do? Are you sure?

class Noddy
{
    int* i;
    Noddy(int *i)
    : i(i)
    {
        if(i == NULL)
            i = new int;
    }
};

Answer 2

No, in this case there are no ambiguity, but consider following:

struct SCustomData {
//...
    void SetCode(int nCode)
    {
            //OOPS!!! Here we do nothing!
            //nCode = nCode;

            //This works but still error prone
            this->nCode = nCode;
    }
};

You should draw attention to one of existing coding styles. For instance General Naming Rule in Google C++ Coding Styles or read excellent book "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Herb Sutter and Andrei Alexandrescu.

Answer 3

If you're referring to using the same name for members and constructor arguments, then that's absolutely fine. However, you might find some people who insist that it's bad practice for some reason.

If you need to access the members in the constructor body, then you need to be careful - either give the arguments different names, or use this-> to access members.

If you're referring to using pseudoHungarian warts to remind people that integers are integers, then that is technically allowed, but has absolutely no benefits and makes the code much harder to read. Please don't do it.

Answer 4

In general, I've prefixed instance variables with underscores and named parameters in the constructor without any prefixes. At the very least, this will disambiguate your parameters from your instance variables. It also makes life less hectic if initializing within the body of the constructor.

struct SCustomData {
    int _nCode;
    int _nSum;
    int _nIndex;
    SCustomData(int nCode, int nSum, int nIndex)
        : _nCode(nCode), _nSum(nSum), _nIndex(nIndex)
    {}
};

// Alternatively
struct SCustomData {
    int _nCode;
    SCustomData(int nCode)
    {
        this->_nCode = nCode;
    }
};

I don't like stacking the variables the way it was written in the question. I like to save vertical space, and it's also easier for me to read left-to-right. (This is a personal preference of mine, not a mandatory rule or anything like that.)

Answer 5

It is perfectly standard compliant, but there are compilers out there that would not accept member variables having the same name as constructor parameters. In fact, I had to change my open source library for that reason. See this patch

Answer 6

I would say that this is perfectly fine.

It is my preferred style for constructors that use the initialization list and don't have any code. I think that it reduces confusion because it is obvious which constructor parameter goes to which member.