views:

119

answers:

2

There are 4 operators in C++ which can be overloaded but cannot be overloaded as freestanding (aka nonmember, standalone) functions. These operators are:

  • operator =
  • operator ()
  • operator ->
  • operator []

This thread explains perfectly well the rationale of prohibiting operator = to be a member function. Any ideas about the 3 others? TIA

EDIT: Apparently ->* is not one of them, I was mislead by "C++ in a Nutshell" (an otherwise outstanding book).

+3  A: 

The four operators mentioned in the original posting, =, (), -> and [], must indeed be implemented as non-static member functions (by respectively C++98 §13.5.3/1, §13.5.4/1, §13.5.5/1 and §13.5.6/1).

Bjarne Stroustrup's rationale was, as I recall from earlier debates on the subject, to retain some sanity in the language, i.e. having at least some things you could rely on no matter how much Someone Else has screwed up by defining non-member operators for existing classes.

I'm not sure I completely agree that the restriction really helps with that, but.

EDIT: I consulted Bjarne Stroustrup about this (he's always helpful) but it appears that the apparent inconsistencies of the rules are no more than a case of frozen historical accident. He notes that "It looks worse now than it was then because our rules for lvalues and references have changed since the overloading rules were formulated. I tried to look into this issue again a couple of years ago, but ran out of time before producing a complete proposal."

Cheers & hth.,

PS: "The Design and Evolution of C++" book is great for this kind of question, but unfortunately I don't have it.

Alf P. Steinbach
And what exactly in this case is the principal difference between -> and ->* ? Why one can't be a nonmember while the other can? I am by the way open to answers like "there is no serious reason. It's illogical, but that's the way it is", though I certainly would be disappointed if it was the case
Armen Tsirunyan
@Armen: good question. I don't know. Perhaps this is explained "The Design and Evolution", and if so, perhaps someone who has that book will chime in. I checked in the old ARM, it doesn't seem to discuss it.
Alf P. Steinbach
+1  A: 

This thread on comp.std.c discusses the question.

Francis Glassborow, who was on the committee, stated:

The language designers did not want to support conversions and promotions on the left-hand operand of operator =, nor such on the operand of () and [].

Trying to avoid the situation where:

class A {};

class B { B(A& a) {} };

int operator()(B const& b) { return 0; }


int main(void)
{
    A a;

    // This works even though A doesn't have a () operator
    // It creates a temporary B and calls operator()(B& b)
    return a();                   
}
Dingo
Alf P. Steinbach
"The language designers did not want to support conversions and promotions on the left-hand operand of ()". However they do allow that when a class declares a conversion-function to pointer-to function...
Armen Tsirunyan
@Alf Thanks -- modified.
Dingo
I don't see the validity of the objection. If `B` has `operator()` and can be implicitly created from an `A`, why block it?
GMan
@GMan: See Alf P. Steinbach's comment, "to retain some sanity".
MSalters
@MSalters: I don't see it as insane. :)
GMan
@Armen good point against this style of argument :)
Johannes Schaub - litb