Re: Why is overloading operator. (member operator) forbidden?
On May 14, 10:52 am, Erik Wikstr=F6m <eri...@student.chalmers.se> wrote:
On 14 Maj, 10:35, James Kanze <james.ka...@gmail.com> wrote:
On May 14, 8:12 am, Erik Wikstr=F6m <eri...@student.chalmers.se> wrote:
On 14 Maj, 07:36, "dasca...@gmail.com" <dasca...@gmail.com> wrote:
I was wondering, why is overloading operator. (period) forbidden? It
would make a few odd applications possible (dynamic inheritance and
transparent remote method invocation spring to my mind) and it would
be fairly generic. The only sidecase I can see is that operator.
itself would not be looked up through operator. .
I read that there was previous debate on the subject, but I haven't
been able to find why it was rejected.
There are two reasons against it that I know of, the first being that
the general consensus in the standard committee is that it might
introduce too much trouble* , since a user would never know what will
happen if he uses the .-operator,
By that standard, you couldn't overload any of the operators.
the second is the problem you
mentioned about how to implement the normal behaviour.
The answer to that is also well known: (&obj)->.
And if operator-> is overloaded?
As Sylvester has already indicated, the result of &obj is
normally a pointer, and you cannot overload on a pointer. More
generally, you're the author of the class. If the class is a
smart pointer, you overload ->, and not .; if the class is a
smart reference, you overload ., and not ->. And if the class
is designed to confuse the reader, you overload both.
There have been serious proposals concerning this before. I've
forgotten the issues now, but if I recall correctly, there was
one serious point which would have to be addressed. But it is
definitly doable, and extremely useful. (Logically, I'd say
that it would have to be a member function. But then, I'd say
that about operator& as well.)
I know of no
convincing reason for allowing it since it really would not enable
behaviour that can't be simulated in other ways.
Smart references and proxies.
* In fact a recent proposal (n2200) suggests that all operators,
except . (member selection), :: (namespace) and .* (memberpointer),
should be overloadable both as members and non member (that includes
new and delete).
Hmmm. I'll have to look at it, but I'd be very surprised if
they allow the assignment operator to be a non-member. That
would cause no end of problems. (I'm also curious with regards
to ?:. I don't think I'd like to see it overloadable unless
there was a requirement that the first argument be a user
defined type.)
operator= was one of them specifically mentioned, (along with *_cast)
but I think that I was too quick when I said all operators, I don't
thin ?: was included.
I looked at it. Operator= is mentionned, but anything which
could be a copy assignment is still required to be a member.
You can only do things like operator=( MyClass&, int ) as
non-members.
The proposal is far from being uninteresting. But it is also
rather far from being "ready", and I doubt that there is enough
time left to get it ready before the next version of the
standard.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34