Why can't a class have same name for a function and a data member?

Question

Why can't a c++ class have same name for a function and a data member?

class demo{
    public:
        int size();
    private:
        int size;   
};

int main(){
    return 0;
}


C:\Users\S>g++ demo.c
demo.c:5:7: error: declaration of 'int demo::size'
demo.c:3:7: error: conflicts with previous declaration 'int demo::size()'

Weevily

Answer 1

Suppose you want to take the address of the member-function size(), then you would write this:

auto address = &demo::size;

But it could be very well be the address of the member-data size as well. Ambiguous situation. Hence, it is disallowed by the language specification.

That is not to say that it was impossible for the C++ committee to come up with a solution, but I suppose there is no major gain in doing so. Hence, the Standard simply disallowed it, to keep things simple.

Also, the difference between member-data and member-function becomes less distinguishable visually if one declares the member function size() as:

typedef void fun_type();

struct demo
{
    fun_type size; //It looks like a member-data, but it's a member-function
};

void demo::size()  //define the member function
{
  std::cout << "It is crazy!" << std::endl;
}

int main()
{
    demo d;
    d.size(); //call the function!
}

Output:

It is crazy!

See the online demo : http://ideone.com/ZjwyJ

Now if we can implement member functions as explained above, then it becomes too obvious even to the naked eye that you cannot add another member with same name as:

struct demo
{
    fun_type size;
    int      size; //error - choose a different name for the member!
};

Wait That is not entirely correct, as the story is not finished yet. There is something less obvious I need to add here. You can add more than one member with same name:

typedef void fun_type0();
typedef void fun_type1(int a);
typedef void fun_type2(int a, int b);

struct demo
{
    fun_type0 member;  //ok
    fun_type1 member;  //ok
    fun_type2 member;  //ok
};

This is completely valid code, as each member is a function of different type, so you can define them as:

void demo::member()
{
   std::cout << "member()" << std::endl;
}
void demo::member(int a)
{
   std::cout << "member(" << a << ")" << std::endl;
}
void demo::member(int a, int b)
{
   std::cout << "member(" << a << ", "<< b << ")" << std::endl;
}

Test code:

int main()
{
    demo d;
    d.member();
    d.member(10);
    d.member(200,300);
}

Output:

member()
member(10)
member(200, 300)

Online Demo : http://ideone.com/OM97Q

---

The conclusion...

You can add members with same name, as long as they're function of different types. This is enabled by a feature called member-function-overloading (or simple function-overloading)¹.

^{1. Unfortunately, the language doesn't provide similar feature, say member-data-overloading, for member data, neither do the language provide cross-member-overloading (that allows member-data and member-function to have the same name — the case in the question).}

So here a question naturally arises: do they not cause ambiguity problem? Yes, they do. But the point to be noted is that C++ committee came up with a solution to solve this ambiguity-problem, because they saw a huge gain in doing so, (in case of function-overloading).

But the case in the question remains ambiguous, as the committee didn't come up with a solution, as they didn't see any huge advantage in doing so (as noted before). Also, when I said "C++ committee came up with solution", I do NOT mean that the solution has been Standardized, I merely mean that they knew how the compilers can solve it, and how complex the solution would be.

Girth

Ambiguity is not really an answer. How is it different than if demo::size was an overloaded function? – Playoff

@tenfour: You missed the point completely. The ambiguity was there for overloaded functions as well, but the point is the C++ committee came up with a solution to solve this ambiguity-problem, because they saw a huge gain in doing so. But this case in the question remains ambiguous, as the committee didn't come up with a solution. And when I said "C++ committee came up with solution", I do NOT mean that the solution has been Standardized, I merely mean that they knew how the compilers can solve it, and how complex the solution would be. – Girth

I got the point, but it seems similar to this question where the answer seems to be ambiguity, but the more specific reason is that the committee wanted to make function calls not depend on external context. I wonder if there's a similarly more-detailed answer to this question. (or maybe this IS the answer?) – Playoff

Answer 2

because if you use size in your class somewhere then the compiler does not know what to do. It can be either the int-data-member or it can be the function-pointer. So the compiler is not able to seperate both kind

Preponderate

Answer 3

As an example (Not maybe the best but it might explain it visually):

class Size {
        std::size_t size_;
    public:
        Size(std::size_t s = std::size_t() ) : size_(s){}
        std::size_t operator()() const {
            return size_;
        }
        void operator()(std::size_t s) {
            size_ = s;
        }        
};

class Demo {
    public:
        Size size;
};

int main() {
    Demo d;
    d.size(10);
    std::size_t size = d.size();
    return 0;
}

Basically the variable could be callable as well. So there is no way for the compiler to know your intentions. Of course this is defined by the language that it shall not be possible to have the same name as identifier within the same scope.

Ics