Why is overloading operator. (member operator) forbidden?

Discussion in 'C++' started by dascandy@gmail.com, May 14, 2007.

  1. Guest

    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
    , May 14, 2007
    #1
    1. Advertising

  2. On 14 Maj, 07:36, "" <> 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
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, May 14, 2007
    #2
    1. Advertising

  3. Guest

    On 14 mei, 08:12, Erik Wikström <> 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?
    , May 14, 2007
    #3
  4. James Kanze Guest

    On May 14, 8:12 am, Erik Wikström <> wrote:
    > On 14 Maj, 07:36, "" <> 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:
    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, May 14, 2007
    #4
  5. James Kanze Guest

    On May 14, 8:12 am, Erik Wikström <> 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:
    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, May 14, 2007
    #5
  6. On 14 Maj, 09:33, "" <> wrote:
    > On 14 mei, 08:12, Erik Wikström <> 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?=, May 14, 2007
    #6
  7. On 14 Maj, 10:35, James Kanze <> wrote:
    > On May 14, 8:12 am, Erik Wikström <> wrote:
    >
    > > On 14 Maj, 07:36, "" <> 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
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, May 14, 2007
    #7
  8. "Erik Wikström" <> wrote in message
    news:...
    > On 14 Maj, 10:35, James Kanze <> wrote:
    > > On May 14, 8:12 am, Erik Wikström <> 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/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
    Sylvester Hesp, May 14, 2007
    #8
  9. "James Kanze" <> wrote in message
    news:...
    > On May 14, 8:12 am, Erik Wikström <> 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/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
    Sylvester Hesp, May 14, 2007
    #9
  10. James Kanze Guest

    On May 14, 10:52 am, Erik Wikström <> wrote:
    > On 14 Maj, 10:35, James Kanze <> wrote:
    > > On May 14, 8:12 am, Erik Wikström <> wrote:


    > > > On 14 Maj, 07:36, "" <> 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:
    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, May 15, 2007
    #10
  11. <> wrote in message
    news:...

    > 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.
    Andrew Koenig, May 16, 2007
    #11
  12. James Kanze Guest

    On May 16, 3:59 pm, "Andrew Koenig" <> wrote:
    > <> wrote in message


    > news:...


    > > 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:
    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, May 16, 2007
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Hunt
    Replies:
    4
    Views:
    11,283
    gullsinn
    Oct 4, 2009
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,756
    Smokey Grindel
    Dec 2, 2006
  3. Hicham Mouline
    Replies:
    0
    Views:
    422
    Hicham Mouline
    Apr 23, 2009
  4. Hicham Mouline
    Replies:
    1
    Views:
    405
    Michael DOUBEZ
    Apr 24, 2009
  5. Mark J. McGinty

    IIS HTTP 403.1 Forbidden: Execute Access Forbidden

    Mark J. McGinty, Dec 9, 2005, in forum: ASP General
    Replies:
    2
    Views:
    342
    Kyle Peterson
    Dec 9, 2005
Loading...

Share This Page