Jump to content
  • Advertisement
Sign in to follow this  
noatom

How would this be a problem?

This topic is 2074 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

While browsing the internet,i found a post with someone asking why you can't overload the "Member access (selection) operator (that's how . is called)".

 

Another user replied with this:

class Y 
{
    public:
        void f();
};

class X 
{
    Y* p;
    Y& operator.() { return *p; }
    void f();
};

void g(X& x)
{
    x.f();  // X::f or Y::f or error?
}

What I don't understand is,how could the compiler get to the conclusion that the user wanted Y::f?

 

I mean we use the dot operator on x,which could return p,which is an Y pointer.I see the f() call,but there is no -> operator in there. Can someone enlighten this?

 

 

 

 

Does the compiler somehow call the -> operator automatically for any returned pointer? If that's true,what if you don't return a pointer?

Edited by noatom

Share this post


Link to post
Share on other sites
Advertisement
It isn't returning a pointer, it would be returning a reference to the object pointed at by 'p' - note the dereference in the operator.() function applied to 'p'.

Share this post


Link to post
Share on other sites

true,it's a reference,but still,you'd have to do: reference.f() .

 

Does the compiler automatically call the dot operator for you or...?

 

it's like: x.(dot returns reference)reference(something happens)call f() ?

Edited by noatom

Share this post


Link to post
Share on other sites

I'm confused about what you are actually asking about. Are you asking about what would theoretically happen if you could overload it?

 

In practice, the language simply forbids you from overloading it. Compiling your code in MSVC 2012 gives the following:

error C2800: 'operator .' cannot be overloaded

Share this post


Link to post
Share on other sites

No,that's not what im asking.

 

Look at this: when the compiler sees the dot operator,it immediatly returns a reference to Y.

 

In the above example,it says that somehow,the compiler might call the f member function of y.

 

HOWEVER,after the reference is returned there is NO other operator around.

 

Something like:

 

referencef()

 

How would the compiler know to add a dot operator between reference and f() so it would become reference.f() ?

OR

if the dot operator returned a pointer,how would the compiler know how to add a -> operator,so it would become reference->f() ?

Share this post


Link to post
Share on other sites
That particular block is a quote from a stackoverflow question, and their site points out that it is a quote from The Design and Evolution of C++.

The problem is that the code cannot compile. It is ambiguous. There is no way to force it to always work.

There must be some canonical way to access members. Without it the language quickly breaks down.

No matter how hard you try to restrict it, once you allow people to modify the member access operator then some creative individual will find a way to break the absolutely required functionality. There must be a canonically guaranteed way to access members; if not through the dot operator, then through some other operator. Since that was already the purpose of the dot operator they left it alone. They could have allowed overriding the dot operator, but if they had done so then they would have been required to add some other operator for the same purpose.

Share this post


Link to post
Share on other sites

If you assume that the x.f() returns the reference to y and calls Y::f, how would you call X::f?

If you assume that x.f() calls the X::f, how would you obtain the reference to Y and call Y::f?

That's the reason you can't overload it. It's ambiguous (just as frob said), and the compiler can't possibly know what you actually want to do when you invoke x.f(), and so could potentially generate code that doesn't do what you actually had in mind.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!