Why is overloading operator. (member operator) forbidden?

D

dascandy

Hello,

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.

I sent this message to the Boost mailing list, in error, they referred
me to Usenet.

Thanks,

Peter
 
?

=?iso-8859-1?q?Erik_Wikstr=F6m?=

Hello,

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.

I sent this message to the Boost mailing list, in error, they referred
me to Usenet.

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, the second is the problem you
mentioned about how to implement the normal behaviour. I know of no
convincing reason for allowing it since it really would not enable
behaviour that can't be simulated in other ways.

* 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).
 
D

dascandy

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, the second is the problem you
mentioned about how to implement the normal behaviour. I know of no
convincing reason for allowing it since it really would not enable
behaviour that can't be simulated in other ways.

I was thinking of a few things in particular, mainly allowing
transparent forwarding of interfaces. Given variadic templates and an
overloadable operator. you could define a function as such:

template <typename R, typename... Argtypes>
auto operator.(std::string funcname, Argtypes... args) { return
memfun(this, new gen_send<R, ArgTypes...>(funcname); }
template <typename R, typename... Argtypes>
class gen_send {
private:
string funcname;
public:
R &operator()(Argtypes... arguments) {
// serialize and send
// wait for return value, return value
}
};

that would allow transparently forwarding of the function called,
irrelevant of which function it was. Marshalling the return type might
cause one or two small bits of trouble but I think there's a fairly
easy way around that.
* 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).

Wouldn't that cause trouble with typeid and especially sizeof?
 
J

James Kanze

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)->.
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.)
 
J

James Kanze

* 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).

Just a note, but the proposal *does* propose allowing . and .*
to be overloaded. It also retains the restriction that copy
assignment must be a member.

Regretfully, it doesn't seem to say much about the syntax of the
new overloads; just saying that "." should be added to the table
of overloadable operators isn't enough, since it does need some
special treatment. (Like ->, it is a binary operator, but the
second operand is something you can't pass as a parameter.)

Note that anybody can propose anything, and the committee is
required to enregister the proposal, and vote on it. In this
case, the proposal does seem serious, but I fear that it is too
late for it to receive serious consideration. The proposal to
allow overloading operator new and operator delete as
non-members, in particular, would require significant
discussion---to begin with, I'm not sure it's implementable, and
their proposal certainly seems ambiguous with current use (and
would break significant amounts of existing code). So I fear
that the proposal is dead on arrival.
 
?

=?iso-8859-1?q?Erik_Wikstr=F6m?=

I was thinking of a few things in particular, mainly allowing
transparent forwarding of interfaces. Given variadic templates and an
overloadable operator. you could define a function as such:

template <typename R, typename... Argtypes>
auto operator.(std::string funcname, Argtypes... args) { return
memfun(this, new gen_send<R, ArgTypes...>(funcname); }
template <typename R, typename... Argtypes>
class gen_send {
private:
string funcname;
public:
R &operator()(Argtypes... arguments) {
// serialize and send
// wait for return value, return value
}

};

that would allow transparently forwarding of the function called,
irrelevant of which function it was. Marshalling the return type might
cause one or two small bits of trouble but I think there's a fairly
easy way around that.


Wouldn't that cause trouble with typeid and especially sizeof?

Ah, I missed those. I didn't read the whole of the proposal, but I
don't think those were included (nor ?:).
 
?

=?iso-8859-1?q?Erik_Wikstr=F6m?=

By that standard, you couldn't overload any of the operators.


The answer to that is also well known: (&obj)->.

And if operator-> is overloaded?
Smart references and proxies.


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.
 
S

Sylvester Hesp

Erik Wikström said:
And if operator-> is overloaded?

You can't overload operators for pointers, so that shouldn't matter.
However, you can overload the unary & to not return a pointer to your object
(for example, in case of smart references, a typical & operator would return
a smart pointer). Btw, there is a proposal to overload the . and .*
operators:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf. One of
the proposed (and imho the best) ways to get the old behaviour if . were to
be overloaded, is:

addressof(x)->x_member

where addressof(x) is the function as declared in boost:

template<class T> T * addressof(T & t)
{
return reinterpret_cast<T*>(
&const_cast<char*>(
reinterpret_cast<const volatile char &>(t)));
}

- Sylvester
 
S

Sylvester Hesp

James Kanze said:
Just a note, but the proposal *does* propose allowing . and .*
to be overloaded. It also retains the restriction that copy
assignment must be a member.

Regretfully, it doesn't seem to say much about the syntax of the
new overloads; just saying that "." should be added to the table
of overloadable operators isn't enough, since it does need some
special treatment. (Like ->, it is a binary operator, but the
second operand is something you can't pass as a parameter.)

It's in a seperate (earlier) proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf. The
recently published new state of C++ evolution
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2228.html) now
also states it as an active topic in Evolution, which surely sounds
promising.

- Sylvester
 
J

James Kanze

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.)
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.
 
A

Andrew Koenig

I was wondering, why is overloading operator. (period) forbidden?

Because no one ever brought a coherent, workable proposal to the standards
committee for how the feature should be defined. There was one person--I
forget his name--who made such a proposal on Usenet, but whenever anyone
tried to ask questions about potential problems with his proposal, he became
angry. This anger discouraged others from pursuing the issue.
 
J

James Kanze

Because no one ever brought a coherent, workable proposal to
the standards committee for how the feature should be defined.
There was one person--I forget his name--who made such a
proposal on Usenet, but whenever anyone tried to ask questions
about potential problems with his proposal, he became angry.
This anger discouraged others from pursuing the issue.

IIRC, he did make a formal proposal. As you said, however,
there was a personality clash, with the result that the
discussion generated more heat than light, and the concrete
issues didn't get addressed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,829
Latest member
PIXThurman

Latest Threads

Top