In article <D1AFJt.n7@cix.compulink.co.uk>, mwoolf@cix.compulink.co.uk ("Matthew Woolf") writes:
[..]
|> If member names _automatically_ yielded pointers to members, the rather
|> silly definition of overloaded operator->() could be changed to
|> operator->(member_type class_type::*rhs), and the operator would then
|> become a binary op whose right hand side was a pointer to a member. This
|> could then be extended to other binary operators ("class[member]",
|> "class*member", etc) and would allow overloading of -> with other types
|> ("class->6", "class->"string"").
|>
|> Even existing code could be preserved by leaving the (rather silly) unary
|> definition of operator-> intact. Any see any problems?

Interesting idea.
Please note: unary operator->() like operator*() is not silly. They are needed
to implement userdefined pointerclasses (e.g. smart pointers).
With binary operator-> you need to define a method for every member_type.

--
In the case of instance->6 and instance->"string" (suppose you meant instance
not class) this looks like a kind of indexing.
Only allowing literal constants (6,"string") does not make
much sense. Then you could also write o->six, o->string.
When also values are allowed, what is the semantics of binary operator->?

 int val;
 instance->val;

Is 'val' the value of the local variable 'val' or does val stand for the pointer
to member 'val'?
All this is done better by overloading operator[]().

--
Let's get back to memberpointers. It would be unorthogonal that
(I'm not sure if I got the syntax right):

    instance->int_member;
 == instance.operator->(&Class::int_member);
calls
 Class::operator->(int Class::*);

but that
 int  Class::*memptr = &Class::int_member;
 instance->memptr;

does not work althought the type of memptr matches the parameter of operator->.
But (equally to above) what happens then with

 int  Class::*int_member = &Class::int_member;
 instance->int_member;

--
We already have an operator->* that takes pointers to members.
Overloading it (which is not allowed now, as far as I know) would not
introduce new ambiguities. (Like overloading unary operator-> doesn't).

 instance->*memptr;
 instance->*(&Class::int_member);

would call:

 Class::operator->*(int Class::*);

This would give you a kind of binary operator->. When you want it,
you should propose OVERLOADING OPERATOR->*(). And you should give
examples to demonstrate its usability. (I can't think of one now).

Unfortunatly I don't see how the longwinded (&Class::int_member)
could be reduced to int_member without introducing new ambiguities
(see above).


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de

In <3e1l3e$enf@hpsystem1.informatik.tu-muenchen.de> schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:

>We already have an operator->* that takes pointers to members.
>Overloading it (which is not allowed now, as far as I know) would not
>introduce new ambiguities.

 ->* has been overloadable for quite some time.  See ARM 13.4, p.
 330.
--
 - Paul J. Lucas   #ifndef OBVIOUS
   AT&T Bell Laboratories #include <stddisclaimer.h>
   Naperville, IL  #endif

I like it that symbols yield pointers in C++. E.g. short a[9] declares a
symbol 'a' that is auto-initialised to be a constant pointer to 18 bytes
of memory, and int f() declares a symbol 'f' that points to some code.
(Given that one points to code and the other data I am suprised that I
need different operators to dereference them - but that's another story!)

If member names _automatically_ yielded pointers to members, the rather
silly definition of overloaded operator->() could be changed to
operator->(member_type class_type::*rhs), and the operator would then
become a binary op whose right hand side was a pointer to a member. This
could then be extended to other binary operators ("class[member]",
"class*member", etc) and would allow overloading of -> with other types
("class->6", "class->"string"").

Even existing code could be preserved by leaving the (rather silly) unary
definition of operator-> intact. Any see any problems?