Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Why is overloading operator. (member operator) forbidden? (http://www.velocityreviews.com/forums/t506285-why-is-overloading-operator-member-operator-forbidden.html)

dascandy@gmail.com 05-14-2007 05:36 AM

Why is overloading operator. (member operator) forbidden?
 
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?= 05-14-2007 06:12 AM

Re: Why is overloading operator. (member operator) forbidden?
 
On 14 Maj, 07:36, "dasca...@gmail.com" <dasca...@gmail.com> wrote:
> 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@gmail.com 05-14-2007 07:33 AM

Re: Why is overloading operator. (member operator) forbidden?
 
On 14 mei, 08:12, Erik Wikström <eri...@student.chalmers.se> wrote:
> 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 05-14-2007 08:35 AM

Re: Why is overloading operator. (member operator) forbidden?
 
On May 14, 8:12 am, Erik Wikström <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)->.

> 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


James Kanze 05-14-2007 08:49 AM

Re: Why is overloading operator. (member operator) forbidden?
 
On May 14, 8:12 am, Erik Wikström <eri...@student.chalmers.se> wrote:

> * 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


=?iso-8859-1?q?Erik_Wikstr=F6m?= 05-14-2007 08:50 AM

Re: Why is overloading operator. (member operator) forbidden?
 
On 14 Maj, 09:33, "dasca...@gmail.com" <dasca...@gmail.com> wrote:
> On 14 mei, 08:12, Erik Wikström <eri...@student.chalmers.se> wrote:
>
> > 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?= 05-14-2007 08:52 AM

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


Sylvester Hesp 05-14-2007 10:06 AM

Re: Why is overloading operator. (member operator) forbidden?
 

"Erik Wikström" <eriwik@student.chalmers.se> wrote in message
news:1179132776.582986.112130@h2g2000hsg.googlegro ups.com...
> On 14 Maj, 10:35, James Kanze <james.ka...@gmail.com> wrote:
> > On May 14, 8:12 am, Erik Wikström <eri...@student.chalmers.se> wrote:
> > > 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 T> T * addressof(T & t)
{
return reinterpret_cast<T*>(
&const_cast<char*>(
reinterpret_cast<const volatile char &>(t)));
}

- Sylvester



Sylvester Hesp 05-14-2007 10:53 AM

Re: Why is overloading operator. (member operator) forbidden?
 
"James Kanze" <james.kanze@gmail.com> wrote in message
news:1179132566.164183.93860@o5g2000hsb.googlegrou ps.com...
> On May 14, 8:12 am, Erik Wikström <eri...@student.chalmers.se> wrote:
>
> > * 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 05-15-2007 07:15 AM

Re: Why is overloading operator. (member operator) forbidden?
 
On May 14, 10:52 am, Erik Wikström <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öm <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ée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



All times are GMT. The time now is 11:50 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.