none
why :: . .* can not be overloaded RRS feed

  • Question

  • hello people,

     i m into c++ for quite some time..

     .. i hav a doubt why

      :: (scope resolution; )

    . (member selection )

    .* (member selection through pointer to function)

    operator can't be overloaded ???

     in

    "The C+ + Programming Language Third Edition"

    its written that " They take a name, rather than a value, as their second operand and provide the primary means of  referring to members. Allowing them to be overloaded would lead to subtleties [Stroustrup,1994]."

    please help me to understand above sentence...

     

     

    Wednesday, November 8, 2006 9:06 AM

Answers

  • For one, allowing such overloads would rip the language apart. Second of all, it would make quite optimizations a lot more difficult, as all function resolution would have to be done at runtime (as opposed to compile time).

    What Stroustrup means is that the names given to the operators aren't strings brought into the compiled application, as it is with the operands to e.g. operator+. When the application is compiled, the names are mapped to addresses, such as vcall, vtbl, functions or pointers to any of them. The language would have to undergo major changes to allow this, and with very little gain. There are plenty of other ways to affect the program flow at runtime, without having to resort to changing the inner mechanics of the classes and structs in question.

    Wednesday, November 8, 2006 9:17 AM
    Moderator

All replies

  • For one, allowing such overloads would rip the language apart. Second of all, it would make quite optimizations a lot more difficult, as all function resolution would have to be done at runtime (as opposed to compile time).

    What Stroustrup means is that the names given to the operators aren't strings brought into the compiled application, as it is with the operands to e.g. operator+. When the application is compiled, the names are mapped to addresses, such as vcall, vtbl, functions or pointers to any of them. The language would have to undergo major changes to allow this, and with very little gain. There are plenty of other ways to affect the program flow at runtime, without having to resort to changing the inner mechanics of the classes and structs in question.

    Wednesday, November 8, 2006 9:17 AM
    Moderator
  • Thanks for your reply.. but i am not able to understand what u have written .
     plaz explain with some examples..

    Manish Sharma

    Thursday, November 9, 2006 10:14 AM
  • It's hard to spell it out any differently, and still be correct.

    A far fetched real-world example: Imagine that you have to plan your day ahead, down to which busses to take, and where to take them. It's absolutely crucial for you to do this, otherwise you may not be able to catch all connecting routes, and make your travels as effective as possible. Consider then, if you were no longer able to plan ahead, because you wanted to get on busses based on their color, rather than where and when they are going. You may still end up where you want at the end of the day, but it would be impossible for you to plan ahead.

    Allowing function resolution to be done at runtime, instead of compiletime, would be similar to that bus situation. The compiler is no longer able to plan ahead. In addition, the compiler would have to bring function identifications into the compiled code, so your overloaded operators would know which function you were trying to reach.

    The closest you'll get to working around this language limitation, is to use templated classes, function pointers, jump tables or other flow-of-control methods.

    Thursday, November 9, 2006 10:55 AM
    Moderator
  • If you ask a technical question, you're going to get a technical answer.  The operators you've mentioned aren't logical or mathematical operators -- they're fundamental pieces of the C++ language.  You can't overload them because, as einaros said, it would break the language.  You'd end up with "code" like this:

    MyClass obj1;
    MyDerivedClass obj2;
    int MyResult = obj1::obj2;
    int MyFavoriteNumber = obj1::GenerateFavoriteNumber(obj2::MyValue::(0xffce));

    int MyAlternateResult = obj1::(obj1.*(char)(this->value));
    int MyOtherResult = obj1::obj2::foo(obj1::obj2, obj2.value.((float)3.05).toString(), obj2.value::obj2.((float)3.1));

    Even typing stuff like that hurts!  No compiler on the planet could make sense of that garbage, and no human is going to ever be able to make sense of it once it's been written.  C++ provides an incredible amount of extensibility, but it needs to enforce some limits.

    Thursday, November 9, 2006 2:40 PM