Why is operator. not overridable?
Hi, 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. Thanks, Peter
Peter Bindels wrote:
Hi,
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. .
Heh, I think there you have nailed it.
I read that there was previous debate on the subject, but I haven't been able to find why it was rejected.
And there also was some debate on overloadable whitespace operator: http://www.research.att.com/~bs/whitespace98.pdf Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 2007-05-11T11:54:24-0400, Stefan Seefeld wrote:
And there also was some debate on overloadable whitespace operator:
Allan Wind wrote:
On 2007-05-11T11:54:24-0400, Stefan Seefeld wrote:
And there also was some debate on overloadable whitespace operator:
http://www.research.att.com/~bs/whitespace.html
/Allan
That was both amusing and alarming. The chaos that would cause! Very relieved to see it was a joke :)
On Fri, May 11, 2007 at 11:54:24AM -0400, Stefan Seefeld wrote:
And there also was some debate on overloadable whitespace operator:
This is simply fantastic. I am going to revise all my way of writing code. This is the template metaprogramming, isn't? I have only a 2D-display, this explain why I am not able to read all those compilation errors! cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Peter Bindels 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.
This is a bit off-topic, but you might consult Stroustrup. In his "The C++ Programming Language" (3rd or Special edition) he says in section 11.2, in reference to operator. and 2 others that can't be overloaded: "They take a name, rather than a value, as their second operand and provide the means of referring to members. Allowing them to be overloaded would lead to subtleties." And he refers to his "The Design and Evolution of C++" (Addison-Wesley, 1994). -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
This is a bit off-topic, but you might consult Stroustrup. In his "The C++ Programming Language" (3rd or Special edition) he says in section 11.2, in reference to operator. and 2 others that can't be overloaded: "They take a name, rather than a value, as their second operand and provide the means of referring to members. Allowing them to be overloaded would lead to subtleties." And he refers to his "The Design and Evolution of C++" (Addison-Wesley, 1994).
D&E contains the discussion in 11.5.2, "Smart References". Sebastian Redl
Richard Hadsell wrote:
This is a bit off-topic, but you might consult Stroustrup. In his "The C++ Programming Language" (3rd or Special edition) he says in section 11.2, in reference to operator. and 2 others that can't be overloaded: "They take a name, rather than a value, as their second operand and provide the means of referring to members. Allowing them to be overloaded would lead to subtleties."
Easy fix: use functors. obj.func(); would actually do struct anonymous_1 { /* some compile-time reflection info here */ typedef boost::mpl::vector_c<char, 'f', 'u', 'n', 'c'> name; static const bool function = true; typedef boost::mpl::vector<> args; template<typename T> auto operator(T& t) -> decltype(t.func()) { return t.func() } }; obj.operator.(anonymous_1()); I think this would allow, for example, to directly call the member functions of the underlying object in boost.variant. Could someone confirm that?
on Fri May 11 2007, "Peter Bindels" <dascandy-AT-gmail.com> wrote:
Hi,
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.
This is not really the right forum for that question. I suggest comp.std.c++ or comp.lang.c++.moderated. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
participants (10)
-
Allan Wind -
David Abrahams -
Domenico Andreoli -
Jeff Garland -
Mathias Gaunard -
Peter Bindels -
Richard Day -
Richard Hadsell -
Sebastian Redl -
Stefan Seefeld