In article <19940521.2332@naggum.no>, <erik@naggum.no> writes:
> Newsgroups: comp.lang.c++,comp.std.c++
> Subject: Re: How does this function work?
>
> [Bjarne Stroustrup]          <-- left in only for credibility...
..
>
> doesn't this also go to show the distinction between -> and . to be
> rather annoying, and pointless?
>
> it used to be that int (*foo)() had to be called as (*foo)(), but now we
> can say foo(), which is intuitive, and simple because the compiler _knows_
> it's a pointer.  but the language insists on a special operator for
> pointers: (*classptr).foo becomes classptr->foo instead of classptr.foo.
>
> can I move that . be treated as -> when the left-hand argument is a
> pointer to a class?
> could this be considered before the standard is cast in stone?
>
> best regards,
> </Erik>
-----------
1) I agree that this is a nice suggestion. It does have the effect that
it lessens the type-checking ability of the compiler, in allowing one to
inerchangeably use pointers and object/references. One form, with two
permitted type participants.
If this is good or bad is a matter of taste.
I think that automatic de-referencing by context is good,
and in that direction....

2) Aa a related proposal,
I would like to request a similar option;
the ability to invoke operator() from a pointer to an object without the
cumbersome dereferencing systax, "just like" on function pointers.

   Obj o1, *op = &o1;
   o1();               // calls Obj::operator()
   (*op)();            // same, but inconvienent...
   op();               // Same; proposed...!!

3) What I would REALLY like is mutable references;
 which would allow one to reset the reference to the desired object,
 and then the reference semantics would take care of the desired
 dereferencing (which otherwise we are asking the compiler to do,
 as above)
 References merge two unrelated aspects, automatic dereference,
 and const. Seperate them (principle of orthogonality).
 A syntax for it should not be a reason against this, (there's
 plenty of new syntax in C++!)  E.g. any L-value use of & could be
 a reference update, this seems consistent with the declaration syntax.
      int i, j, &ir = &i;
      &ir = &j;          // alter reference...
 They would subsume both of these proposals, albeit not as convienently.

These (#2,#3) seem completely upward compatible, and a great notational
convience with useful aplications.

Any reasons NOT to allow it??

Greg Guthrie

In article <2s5dur$4ut@news.iastate.edu> guthrie@miu.edu writes:
>
>3) What I would REALLY like is mutable references;

 You already have them:

 struct X {
  Y& y;
  X(Y& yy) : y(yy) {}
 };

 Y y1, y2;
 X x(y1);
 ...
 x.~X();
 new(&x) X(y2);
 ...

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <19940521.2332@naggum.no> Erik Naggum <erik@naggum.no>
writes:

|> doesn't this also go to show the distinction between -> and . to be rather
|> annoying, and pointless?

|> it used to be that int (*foo)() had to be called as (*foo)(), but now we
|> can say foo(), which is intuitive, and simple because the compiler _knows_
|> it's a pointer.

On the other hand, it might be considered good style to still write
"(*foo)()."  Or do you have some particular reason for wanting to hide
the fact that the function call is indirect from the reader?

|> but the language insists on a special operator for
|> pointers: (*classptr).foo becomes classptr->foo instead of classptr.foo.

|> of course, this is most annoying when you use typedefs, and still have to
|> remember whether something is a pointer or an object.

|> can I move that . be treated as -> when the left-hand argument is a pointer
|> to a class?  could this be considered before the standard is cast in stone?

Only if you can define what happens with regards to the overloaded
"operator->()."  Generally speaking, both . and -> are valid on a
class; . works as it did in C, and -> calls the operator->() member
function (supposing such exists).
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

[Bjarne Stroustrup]

|   Nothing. You are right. This is an embarrasing bug. I have found and
|   fixed it on teaching materials I use, but somehow the correction hasn't
|   made it into the books:
|
|    void rotate_all(shape* v[], int size, int angle)
|        // rotate all members of array "v" of size "size"
|        // "angle" degrees
|    {
|        int i = 0;
|        while (i<size) {
|     v[i]->rotate(angle);
|     i = i+1;
|        }
|    }
|
|   Now, I too find it hard to believe that ``no one else would have
|   noticed and pointed it out to the author before now'' but a quick look
|   through my filespace shows no comments on this function in the hundreds
|   of messages I have received about the books. Amazing.

doesn't this also go to show the distinction between -> and . to be rather
annoying, and pointless?

it used to be that int (*foo)() had to be called as (*foo)(), but now we
can say foo(), which is intuitive, and simple because the compiler _knows_
it's a pointer.  but the language insists on a special operator for
pointers: (*classptr).foo becomes classptr->foo instead of classptr.foo.

of course, this is most annoying when you use typedefs, and still have to
remember whether something is a pointer or an object.

can I move that . be treated as -> when the left-hand argument is a pointer
to a class?  could this be considered before the standard is cast in stone?

best regards,
</Erik>
--
Erik Naggum <erik@naggum.no> <SGML@ifi.uio.no>  |  memento, terrigena.
ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS  |  memento, vita brevis.