gennaro_prota@yahoo.com (Gennaro Prota) wrote in message
news:<l2kuou4p336m2cr2pb2bmolfi3nufd9ce8@4ax.com>...
> On Mon, 23 Sep 2002 14:38:26 +0000 (UTC), kanze@gabi-soft.de (James
> Kanze) wrote:

> >I think that the question is more complex than that.  The operator.()
> >does introduce a number of problems.  They aren't insurmountable, and
> >the utility of the operator is patent.  At the time, however, the
> >proponent of operator.() was not able to address the problems,

> This is also covered in one of Bjarne Stroustrup's FAQs, yes.

> >partially for political reasons

> In the sense that other people were more interested in their own
> proposals?

In several ways.  To begin with, the proponent could not join ANSI
(supposing he had wanted to) in order to defend his proposition, because
ANSI rules do not allow an individual to be a member if his employer is
a member.  Since the proponent's employer was a member, but didn't give
a hoot about the proposal, there wasn't much he could do directly.  (The
rule is to prevent large companies from stuffing the committee.)

One might add that the proponent wasn't always as diplomatic as he could
have been, too.  Insulting members of the committee is not the best way
to get them to work for something YOU want.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 24 Sep 2002 16:04:44 +0000 (UTC), kanze@gabi-soft.de (James
Kanze) wrote:

>One might add that the proponent wasn't always as diplomatic as he could
>have been, too.  Insulting members of the committee is not the best way
>to get them to work for something YOU want.

Ah. Actually I was under the impression that the proponent was B.
Stroustrup himself. Of course from what you say it's evident that it
was someone else.

Thanks,
Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

This issue has been debated extensively on this newsgroup in the past.
A Google search for "comp.std.c++ operator dot" pulls up 187 hits,
going back to 1990, most of which look relevent.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

lundblad@linux.nu (Peter N. Lundblad) wrote in message
news:<b396bb55.0209182210.3fc4c6b3@posting.google.com>...

    [With regards to operator.()...]
> Well, I am probably fighting windmills, so I should probably just give
> up and accept that the language is like it is. Still, though, I am not
> convinced whether this feature wasn't seen as being enough useful to
> motivate solving the problems with it when it was considered.

I think that the question is more complex than that.  The operator.()
does introduce a number of problems.  They aren't insurmountable, and
the utility of the operator is patent.  At the time, however, the
proponent of operator.() was not able to address the problems, partially
for political reasons, and various other people had other priorities, or
more important things to do -- the operator was useful, but regretfully,
it wasn't a priority of anyone in a position to address the issues.

I think that the development of generic programming may have made its
presence more important, and I wouldn't exclude a proposal for it in the
next round of standardizing.  If the people behind the proposal are
prepared to address the issues raised by the committee, I wouldn't even
be surprised if it passed.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 23 Sep 2002 14:38:26 +0000 (UTC), kanze@gabi-soft.de (James
Kanze) wrote:

>I think that the question is more complex than that.  The operator.()
>does introduce a number of problems.  They aren't insurmountable, and
>the utility of the operator is patent.  At the time, however, the
>proponent of operator.() was not able to address the problems,

This is also covered in one of Bjarne Stroustrup's FAQs, yes.

>partially
>for political reasons

In the sense that other people were more interested in their own
proposals?


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

alaa@annosoor.org (Alaa The Great) wrote in message news:<amap48$4835u$1@ID-148116.news.dfncis.de>...
> On Wed, 18 Sep 2002 22:04:24 +0300, Peter N. Lundblad wrote:
>
> > Hi,
> >. Now, my question is
> > what the rationale for not allowing overloading of operator.() was.
>
[...]
> if -> and was also overloaded then it actualy becomes imposible to access
> members at all without passing through an overloaded operator.
>
> while this may be the effect you want this feature would mean that
> programmers can modify the meaning of the language.
> this would lead to code that is very hard to understand and even harder to
> maintain.
>
But you would only be able to modify it for new types, as with other
operators.

> I think TDaEoC++ also mentions a problem about not being able to create
> real proxy classes (or smart references) since calls to operators will
> not go through the overloaded operator .() _can't find the page though_
>
> ie x+y and x.operator+(y) will have different meanings
>
But wouldn't this be solved for non-member operator functions by a
conversion function? I.e. (illegal):

template<typename T>
class MyRef {
public:
  // ...
  operator T&() const;
  T& operator.() const;
  // ...
};

For operators that are implemented as member functions, the invocation
can be interpreted as a call to the function using the . operator
(i.e. x@y can be transformed into x.operator@(y) and so on.)

Well, I am probably fighting windmills, so I should probably just give
up and accept that the language is like it is. Still, though, I am not
convinced whether this feature wasn't seen as being enough useful to
motivate solving the problems with it when it was considered.

Thanks,
//Peter

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

I am trying to write a standard-compliant container where the objects
are not stored in the same way as the container exposes them. Since it
doesn't seem possible to create a proxy class that behaves like a
reference to an object, I came to the conclusion that it isn't
possible in general (I can have something that looks like a container,
but provides input/output iterators only, for example). Now, my
question is what the rationale for not allowing overloading of
operator.() was. I found a proposal for adding this feature from about
1990 (se <http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=1992Jul14.190540.2425%40microsoft.com&rnum=4&prev=/groups%3Fq%3DC%252B%252B%2Boverloading%2Boperator%2Bmember%2Bselection%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch>).

Like the author of that proposal, I think it would be useful. If we
could overload operator.(), wouldn't it be possible to relax the
restriction that the nested type reference for any iterator category
but input and output iterators has to be a real reference? I didn't
find the rationale for rejecting this proposal from the committee.
Could anyone with more insights please clarify this?

Regards,
//Peter

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 18 Sep 2002 22:04:24 +0300, Peter N. Lundblad wrote:

> Hi,
>. Now, my question is
> what the rationale for not allowing overloading of operator.() was.

I think the rational was that if overloading .() was allowed clients of
class X with operator .() overloaded would loose the ability to access
members in a normal way.
if -> and was also overloaded then it actualy becomes imposible to access
members at all without passing through an overloaded operator.

while this may be the effect you want this feature would mean that
programmers can modify the meaning of the language.
this would lead to code that is very hard to understand and even harder to
maintain.

I think TDaEoC++ also mentions a problem about not being able to create
real proxy classes (or smart references) since calls to operators will
not go through the overloaded operator .() _can't find the page though_

ie x+y and x.operator+(y) will have different meanings

cheers,
Alaa

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]