In article <CE4qnD.33u@apollo.hp.com> vinoski@apollo.hp.com (Steve Vinoski) writes:
|In article <rfgCE3uBy.I4z@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|>I (for one) have never claimed that -> was an operator.  Quite the contrary,
|>I have ALWAYS claimed that the "feature" of C++ which allows overloading of
|>-> was a grave mistake, and that it really ought to be removed from the
|>language.
|
|I strongly second this.  Overloading operator-> causes many more
|problems than it solves (but try to convince C++ novices of that...).

Fine, then you guys convince the committee to remove overloaded
operator->, and I will drop the request for the operator.

Alternately, explain to me how novices are helped by being exposed to:

 obj . doSomething();
 ptr -> doSomething();
 ref . doSomething();
 smartPtr -> doSomething();
 smartRef -> doSomething();

????

In article <KANZE.93Sep20161609@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>
>Would you say that 'operator void*()' is somehow more of an operator
>than 'operator.()'?

Well, casts certain conform more to the general model of unary operators as
things which (a) are followed by general expressions and which (b) yield
values.

>And how would you describe the differences which
>make 'operator->()' and operator, and 'operator.()' not one?

I (for one) have never claimed that -> was an operator.  Quite the contrary,
I have ALWAYS claimed that the "feature" of C++ which allows overloading of
-> was a grave mistake, and that it really ought to be removed from the
language.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCE3uBy.I4z@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>I (for one) have never claimed that -> was an operator.  Quite the contrary,
>I have ALWAYS claimed that the "feature" of C++ which allows overloading of
>-> was a grave mistake, and that it really ought to be removed from the
>language.

I strongly second this.  Overloading operator-> causes many more
problems than it solves (but try to convince C++ novices of that...).

--steve

Steve Vinoski  vinoski@apollo.hp.com    (508)436-5904
Distributed Object Computing Program    fax: (508)436-5122
Hewlett-Packard, Chelmsford, MA 01824

In article <rfgCE3uBy.I4z@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> I (for one) have never claimed that -> was an operator.  Quite the contrary,
> I have ALWAYS claimed that the "feature" of C++ which allows overloading of
> -> was a grave mistake, and that it really ought to be removed from the
> language.

Really ?! At work we use -> overloading for smart pointers and we almost
entirely got rid of C pointer trouble.

 -- marc.

################################################################################
 email  preferred address    marc@offline.be [= me@home]
           aka               marc@offline.UUCP ub4b!offline!marc offline!marc
        if [me@home] fails   mdu@abacus.be [= me@brussels.work]
           or                mdp@cimad.be  [= me@antwerp.work]
 fido   2:292/603.26  Marc.Duponcheel@p26.f603.n292.z2.FidoNet.Org [= me@home]
 bix    mduponcheel   mduponcheel@BIX.com [= me@home]
################################################################################

In article <rfgCDIv6o.AHq@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> In article <KANZE.93Sep16131346@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|> >In article <CDF4D3.C9L@cbnewse.cb.att.com> grumpy@cbnewse.cb.att.com
|> >(Paul J Lucas) writes:

|> >|> From article <1993Sep14.173328.5382@microsoft.com>, by jimad@microsoft.com (Jim Adcock):
|> >|> > In article <CD7Mzp.n3J@cbnewse.cb.att.com> grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:
|> >|> > | For a different example, ordinary unions can have private and
|> >|> > | protected members; the ARM comments on p. 183 that "This is not
|> >|> > | assumed to be a very useful or important feature.  It is simply
|> >|> > | easier to allow it than to disallow it."

|> >|> > Strange that this orthogonality argument was not equally applied
|> >|> > to operator overloading.

|> >|>  Huh?  I hardly think that it's easier to allow operator overloading
|> >|>  than to disallow it.

|> >But it would be easier to allow *all* operators to be overloaded than
|> >only some.  (I think Jim is referring to operator.(), which for some
|> >unknown reason, cannot be overloaded.)

|> A certain group of folks have been moaning about the inability to overload
|> operator. for a long time.

|> No matter how many times this (ridiculous?) subject comes up, the basic
|> fact that `.' is *not* an operator (and never has been) seems to be con-
|> tinuously ignored by the proponents of this silly idea.

Well, the ARM specifically says: "The following OPERATORS cannot be
overloaded: [...] ."  So apparently the authors of the ARM thought of
it as an operator.

I suspect that they probably got this erroneous idea from the C
standard, where '.' is expressedly listed under the operators (and not
under punctuation, like '{'.)  (Sections 6.1.5 and 6.1.6 in the ISO
version.)

Again, I suspect that this is based on the idea that symbols that
operate on other symbols (as opposed to parentheses for grouping)
within an expression are operators.

Would you say that 'operator void*()' is somehow more of an operator
than 'operator.()'?  And how would you describe the differences which
make 'operator->()' and operator, and 'operator.()' not one?  (One
difference, of course, is that you can overload the first, but not the
second.  But in the context of this discussion, that is a circular
argument.)

Followups to comp.std.c++.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung