Re: Why is overloading operator. (member operator) forbidden?
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?
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.
--
Erik Wikstr=F6m