Why is overloading operator. (member operator) forbidden?

[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?=]

On 14 Maj, 07:36, "[e-mail]" <[e-mail]:

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

--
Erik Wikström

[dascandy]

On 14 mei, 08:12, Erik Wikström <[e-mail]:

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?

[James Kanze]

On May 14, 8:12 am, Erik Wikström <[e-mail]:

On 14 Maj, 07:36, "[e-mail]" <[e-mail]:

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

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 14, 8:12 am, Erik Wikström <[e-mail]:

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

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

On 14 Maj, 09:33, "[e-mail]" <[e-mail]:

On 14 mei, 08:12, Erik Wikström <[e-mail]:

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?

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

--
Erik Wikström

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

On 14 Maj, 10:35, James Kanze <[e-mail]:

On May 14, 8:12 am, Erik Wikström <[e-mail]:

On 14 Maj, 07:36, "[e-mail]" <[e-mail]:

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öm

[Sylvester Hesp]

"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@h2g2000hsg.googlegro ups.com...

On 14 Maj, 10:35, James Kanze <[e-mail]:

On May 14, 8:12 am, Erik Wikström <[e-mail]:

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?

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/wg...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 TT * addressof(T & t)
{
return reinterpret_cast<T*>(
&const_cast<char*>(
reinterpret_cast<const volatile char &>(t)));
}

- Sylvester

[Sylvester Hesp]

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...

On May 14, 8:12 am, Erik Wikström <[e-mail]:

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

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

- Sylvester

[James Kanze]

On May 14, 10:52 am, Erik Wikström <[e-mail]:

On 14 Maj, 10:35, James Kanze <[e-mail]:

On May 14, 8:12 am, Erik Wikström <[e-mail]:

On 14 Maj, 07:36, "[e-mail]" <[e-mail]:
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Andrew Koenig]

<da******@gmail.comwrote in message
news:11**********************@u30g2000hsc.googlegr oups.com...

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.

[James Kanze]

On May 16, 3:59 pm, "Andrew Koenig" <[e-mail]:

<[e-mail] in message

news:11**********************@u30g2000hsc.googlegr oups.com...

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.

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.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]