Greg Comeau wrote:

> I don't have my WP handy, but I'm pretty certain there is at least
> an intent assumed where op-> overloading is discussed and that it
> cannot return int *, even if called directly.

I am at least partly reponsible for this change. I proposed that a few
restrictive paragraphs were dropped from the WP to make it easier to
write templates that provided op->

Specifically, there is NO RESTRICTION on the return type of op-> at the
point of declaration.

Nor is there any direct restriction on the return type at the point of a
DIRECT call to operator->().

However, the restrictions on builtin -> still stand so at some point, in
the expression p->m, the invocation(s) of op-> must yield a type for
which the builtin -> can be applied and there must be a member called m.

Example:

 class X {
 public:
  int operator->() { return 0; }
 };
 X x;
 int i = x.operator->(); // legal, if rather strange

> When and why did this change?

Unusually (for me) I don't recall exactly when this changed... one
moment... and my web page doesn't say! www.ocsltd.com/c++/cppopp.html
Sorry! Prior to "July '95" looks likely tho'...
--
Sean A Corfield                                       fax:+441252654077
Technical Director                                 tel/sms:+44385758805
Object Consultancy Services Ltd                   http://www.ocsltd.com
Object technology & C++ Specialists              mailto:sean@ocsltd.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5c8kie$r40$2@news.belwue.de> dietmar.kuehl@uni-konstanz.de writes:
>Hi,
>Greg Comeau (comeau@panix.com) wrote:
>: In article <5bo39n$qij$4@news.belwue.de> dietmar.kuehl@uni-konstanz.de
>: writes:
>: >I don't think that the compiler must diagnose an instantiation of
>: >'operator->()' as error! I think it is legal to write this:
>: >
>: >  template <class T> struct foo { T *operator->() const { return 0; } };
>: >  int main() { foo<int> fi; int *ptr = fi.operator->(); }
>: >
>: >although two out of three compilers disagree (gcc-2.7.2 accepts the
>: >code, KCC-3.1a and SC-4.1 do not). Of course, it would be illegal to
>: >request a member with the 'operator->()' for 'foo<int>'...
>
>: That's right, it would be invalid.  So, could you clarify your point
>: as I did not catch the beginning of this thread.
>
>My point is, that 'foo<T> fi.operator->()' is legal, independent of the
>type 'T', even if 'T' is 'int': It is always allowed to instantiate
>this operator when using function call syntax (at least, I haven't
>found words which prohibit this...). This thread start with asking why
>'operator->()' is not defined for STL iterators (which is no longer
>really the case). It went one to mention that 'operator->()' was
>illegal e.g. in the code snippet above in an older version of the WP.
>It went on to claim that it still is illegal (which is not the case)
>and came to the point where it was claimed (by A.Oliva):

I don't have my WP handy, but I'm pretty certain there is at least
an intent assumed where op-> overloading is discussed and that it
cannot return int *, even if called directly.

>> No problem (except for void main :-), as long as you do not request
>> A<int>::operator->() to be instantiated.  However, if I insert
>> `a->foo();' after the declaration of a, the compiler must diagnose an
>> error.
>
>This statement is, at least I believe this, not exact: You can request
>that 'A<int>::operator->()' (with a being e.g. a class like my 'foo'
>above or 'auto_ptr') be instantiated, as long as you use function call
>syntax. Of course, A.Oliva is correct that 'a->foo()' would be an
>error.  In any case, if you never use 'A<int>::operator->()' it can be
>present without causing any problems:  There is no reason why STL
>iterators should not support 'operator->()' and, in fact, it is even
>required that they do support it.

I thought that at least at the call point, that an int * return was an error,
even in the .op form.  When and why did this change?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 /Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com /CIS:72331,3421
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

|>  Greg Comeau (comeau@panix.com) wrote:
|>  : In article <5bo39n$qij$4@news.belwue.de> dietmar.kuehl@uni-konstanz.de writes:
|>  : >I don't think that the compiler must diagnose an instantiation of
|>  : >'operator->()' as error! I think it is legal to write this:
|>  : >
|>  : >  template <class T> struct foo { T *operator->() const { return 0; } };
|>  : >  int main() { foo<int> fi; int *ptr = fi.operator->(); }
|>  : >
|>  : >although two out of three compilers disagree (gcc-2.7.2 accepts the
|>  : >code, KCC-3.1a and SC-4.1 do not). Of course, it would be illegal to
|>  : >request a member with the 'operator->()' for 'foo<int>'...
|>
|>  : That's right, it would be invalid.  So, could you clarify your point
|>  : as I did not catch the beginning of this thread.
|>
|>  My point is, that 'foo<T> fi.operator->()' is legal, independent of the
|>  type 'T', even if 'T' is 'int': It is always allowed to instantiate
|>  this operator when using function call syntax (at least, I haven't
|>  found words which prohibit this...).

I don't think that this is correct.  At least in the ARM, there is a
restriction that the return value of operator-> must be either a class
type with a user defined operator->, or a pointer to a class or union.

Note that the problem with operator-> in the iterators is NOT that some
compilers instantiated it even if it wasn't used.  The problem was that
the declaration of the function in the class itself (which must be
instantiated) was illegal for built-in types.

The draft standard has added a rule somewhere to the effect that this
restriction will not be checked, at least for template classes, unless
the operator is actually used.  I think (but I am not sure) that it is
still illegal to declare an operator-> outside of a template that
returns int.  Again, I think (but am too lazy to look it up and verify)
that if the templated operator-> is used in any way, the compiler must
enforce this restriction.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) wrote:
: Hi,
: Alexandre Oliva (oliva@dcc.unicamp.br) wrote:
: : Marcelo Cantos writes:
: : > What if I do this?
: : >     void main() { A<int> a; }
: : No problem (except for void main :-), as long as you do not request
:               ^^^^^^^^^^^^^^^^^^^^
: : A<int>::operator->() to be instantiated.  However, if I insert
: : `a->foo();' after the declaration of a, the compiler must diagnose an
: : error.
: I don't think that the compiler must diagnose an instantiation of
: 'operator->()' as error! I think it is legal to write this:
:   template <class T> struct foo { T *operator->() const { return 0; } };
:   int main() { foo<int> fi; int *ptr = fi.operator->(); }
: although two out of three compilers disagree (gcc-2.7.2 accepts the
: code, KCC-3.1a and SC-4.1 do not). Of course, it would be illegal to
: request a member with the 'operator->()' for 'foo<int>'...

13.5.6 Class member access [over.ref] /1
operator-> shall be a non-static member function taking no parameters.
It implements class member access using ->
 postfix-expression -> id-expression
An expression x->m is interpreted as (x.operator->())->m for a class
object x of type T if T::operator->() exists and if the operator is
selected as the best match function by the overload resolution mechanism.

So little says so much.  The return type is not specified.  It need not
be a pointer type.  The "interpreted as" part shows that x-> is not at all
the same as x.operator->().  This makes it possible to define this
operator to do anything returning anything (including void) as long as
it is not used in the operator notation.  This fits in with all of the
other user defined operators and fixes all of the problems in
templates.  Wish I had seen it months ago.  Here is a g++ example.

#include <iostream.h>
struct P1 { int* p; int* operator-> () { return p; } };
struct P2 { int* p; int& operator-> () { return *p; } };
struct S1 { int s; };
struct S2 { S1* sp; S1* operator->() { return sp; } };
int main () {
 int i = { 5 };
 P1 p1 = { &i }; P2 p2 = { &i };
 S1 s1 = { i }; S2 s2 = { &s1 };
 cout
  << (*p1.operator->() == i) << (p2.operator->() == i)
  << (s2->s == i) << (s2.operator->()->s == i) << endl;
 }

Enjoy,
John


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi,
Greg Comeau (comeau@panix.com) wrote:
: In article <5c8kie$r40$2@news.belwue.de> dietmar.kuehl@uni-konstanz.de writes:
: >My point is, that 'foo<T> fi.operator->()' is legal, independent of the
: >type 'T', even if 'T' is 'int': It is always allowed to instantiate
: >this operator when using function call syntax (at least, I haven't
: >found words which prohibit this...).

: I don't have my WP handy, but I'm pretty certain there is at least
: an intent assumed where op-> overloading is discussed and that it
: cannot return int *, even if called directly.

I haven't found any words to this respect in the section discussing
overloading of op->, namely in over.ref (see the article of J.E.Potter
for a complete copy of this section). I browsed through other section
of the DWP, too, but did not find any such restriction.

: I thought that at least at the call point, that an int * return was an error,
: even in the .op form.  When and why did this change?

I don't know when but I think I have an idea why: The current rules
(i.e. what I think what the current rules :-) are simple and
sufficient. I don't think there is any reason to require that op->
returns a pointer to class or struct.

James Kanze (james-albert.kanze@vx.cit.alcatel.fr) wrote with respect
to my example:
> I don't think that this is correct.  At least in the ARM, there is a
> restriction that the return value of operator-> must be either a class
> type with a user defined operator->, or a pointer to a class or union.

I think the rules changed since the ARM. I don't have the ARM handy but
the following, present in the April 95 DWP, was basically removed from
the section over.ref:

  operator->  shall return either a pointer to a class or an object of
  or a reference to a class for  which  operator-> is  defined,  except
  in  some cases when it is a member of a template (see _temp.opref_).
  T::operator-> shall not return an  object  of  or reference to its own
  class type T

As mentioned above, the excerpt in the article from J.E.Potter is the
complete section.

> Note that the problem with operator-> in the iterators is NOT that some
> compilers instantiated it even if it wasn't used.  The problem was that
> the declaration of the function in the class itself (which must be
> instantiated) was illegal for built-in types.

Yes, I know. This is, however, a different change: There are now two
rules why 'auto_ptr<int>' is legal:

1. 'int *auto_ptr<int>::operator->() const' is a valid declaration
2. 'int *auto_ptr<int>::operator->() const' is not checked for
   correctness unless it is instantiated

My point was that 1. is there, too.

John E. Potter (jpotter@falcon.lhup.edu) wrote after discussing why my
example was legal:
> Wish I had seen it months ago.

This was my point :-) It is yet another change many programmers are not
aware of. Not that I think it is very important but good to know.
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5bo39n$qij$4@news.belwue.de> dietmar.kuehl@uni-konstanz.de writes:
>I don't think that the compiler must diagnose an instantiation of
>'operator->()' as error! I think it is legal to write this:
>
>  template <class T> struct foo { T *operator->() const { return 0; } };
>  int main() { foo<int> fi; int *ptr = fi.operator->(); }
>
>although two out of three compilers disagree (gcc-2.7.2 accepts the
>code, KCC-3.1a and SC-4.1 do not). Of course, it would be illegal to
>request a member with the 'operator->()' for 'foo<int>'...

That's right, it would be invalid.  So, could you clarify your point
as I did not catch the beginning of this thread.

- greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi,
Greg Comeau (comeau@panix.com) wrote:
: In article <5bo39n$qij$4@news.belwue.de> dietmar.kuehl@uni-konstanz.de writes:
: >I don't think that the compiler must diagnose an instantiation of
: >'operator->()' as error! I think it is legal to write this:
: >
: >  template <class T> struct foo { T *operator->() const { return 0; } };
: >  int main() { foo<int> fi; int *ptr = fi.operator->(); }
: >
: >although two out of three compilers disagree (gcc-2.7.2 accepts the
: >code, KCC-3.1a and SC-4.1 do not). Of course, it would be illegal to
: >request a member with the 'operator->()' for 'foo<int>'...

: That's right, it would be invalid.  So, could you clarify your point
: as I did not catch the beginning of this thread.

My point is, that 'foo<T> fi.operator->()' is legal, independent of the
type 'T', even if 'T' is 'int': It is always allowed to instantiate
this operator when using function call syntax (at least, I haven't
found words which prohibit this...). This thread start with asking why
'operator->()' is not defined for STL iterators (which is no longer
really the case). It went one to mention that 'operator->()' was
illegal e.g. in the code snippet above in an older version of the WP.
It went on to claim that it still is illegal (which is not the case)
and came to the point where it was claimed (by A.Oliva):

> No problem (except for void main :-), as long as you do not request
> A<int>::operator->() to be instantiated.  However, if I insert
> `a->foo();' after the declaration of a, the compiler must diagnose an
> error.

This statement is, at least I believe this, not exact: You can request
that 'A<int>::operator->()' (with a being e.g. a class like my 'foo'
above or 'auto_ptr') be instantiated, as long as you use function call
syntax. Of course, A.Oliva is correct that 'a->foo()' would be an
error. In any case, if you never use 'A<int>::operator->()' it can be
present without causing any problems:  There is no reason why STL
iterators should not support 'operator->()' and, in fact, it is even
required that they do support it.
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi,
Alexandre Oliva (oliva@dcc.unicamp.br) wrote:
: Marcelo Cantos writes:
: > What if I do this?

: >     void main() { A<int> a; }

: No problem (except for void main :-), as long as you do not request
              ^^^^^^^^^^^^^^^^^^^^
Hehe, this was also the first thing I spotted :-)

 [Me too ;-). -mod.]

: A<int>::operator->() to be instantiated.  However, if I insert
: `a->foo();' after the declaration of a, the compiler must diagnose an
: error.

I don't think that the compiler must diagnose an instantiation of
'operator->()' as error! I think it is legal to write this:

  template <class T> struct foo { T *operator->() const { return 0; } };
  int main() { foo<int> fi; int *ptr = fi.operator->(); }

although two out of three compilers disagree (gcc-2.7.2 accepts the
code, KCC-3.1a and SC-4.1 do not). Of course, it would be illegal to
request a member with the 'operator->()' for 'foo<int>'...
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Kevin Jacobs wrote:
> I was wondering if there are any subtle reasons why STL and the Daft
> standard do not overload operator-> for iterators.
[snipped]
> It would be clearer to write:
>
>     for( vector<int>::iterator i = v.begin(); i != v.end(); ++i )
>       i->print();
>
> I know this may seem ambiguous since most people expect operator-> to
> function only on pointer types, but my view is that iterators are safe
> pointer wrappers and should be expected to act similarly.

You're suggesting this:

    template <class T> class A {
        A *operator->() { return m; }
        T *m;
    }

What if I do this?

    void main() { A<int> a; }

the 'operator->()' member means that a->b is actually processed as
a.m->b. In this case, a.m is a pointer to int! There is no such thing
as int::operator->, hence the above code yields a compile-time error.
I believe it is still an error if 'operator->()' is only declared and
not defined, eg:

    A *operator->();

Hence a template class with such an operator can only be instantiated
on a compound type (struct, union or class).  In fact the example
given above is illegal anyway; a built-in type (int) has no member
functions (int::print()).

--
__________________________________________________
Marcelo Cantos                  Research Assistant
Multimedia Database Systems Group, RMIT, Australia
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marcelo Cantos writes:

> Kevin Jacobs wrote:
>> I was wondering if there are any subtle reasons why STL and the Daft
>> standard do not overload operator-> for iterators.
> [snipped]
>> It would be clearer to write:
>>
>> for( vector<int>::iterator i = v.begin(); i != v.end(); ++i )
i-> print();
>>
>> I know this may seem ambiguous since most people expect operator-> to
>> function only on pointer types, but my view is that iterators are safe
>> pointer wrappers and should be expected to act similarly.

>     template <class T> class A {
>         A *operator->() { return m; }
//        ^ I think you meant T *, not A *, right?
>         T *m;
>     }

> What if I do this?

>     void main() { A<int> a; }

No problem (except for void main :-), as long as you do not request
A<int>::operator->() to be instantiated.  However, if I insert
`a->foo();' after the declaration of a, the compiler must diagnose an
error.

In fact, such operator is a requirement of all iterators except Output
iterators, as of Nov'96 DWP.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Kevin Jacobs <jacobs@darwin.mhmc.CWRU.Edu> writes:

> Hello fellow C++ programmers.
>
> I was wondering if there are any subtle reasons why STL and the Daft
> standard do not overload operator-> for iterators.

Originally, the reason was simple: the language didn't allow it.

Specifically, consider an iterator that points to a built-in type;
just to be concrete, think about list<int>::iterator.  If iter is a
list<int>::iterator, then it's clearly an error to write (for example)
iter->f().  Suppose, however, that you define list<T>::iterator to
have a member operator->() and that you don't ever use it for the case
when T is an int; what then?  It was once the case that it would an
error to instantiate this class with int, even if you never actually
used operator-> at all.  This was true at the time when the STL was
originally written, so it simply wouldn't have been possible to
define operator-> for iterators.

This reason no longer applies, and the draft standard now says (see
table 73, in section 24.1.1) that iterators do define operator->.  At
this point, however, not all compilers implement the new rules.  As a
result, most library implementations don't yet include this feature.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hello fellow C++ programmers.

I was wondering if there are any subtle reasons why STL and the Daft
standard do not overload operator-> for iterators.

ie.:
  #include <vector>
  #include <stream.h>
  class A
  {
    public:
      void print() { cout << "A!" << endl; }
  };

  int main()
  {
    vector<A> v;
    // ...

    for( vector<int>::iterator i = v.begin(); i != v.end(); ++i )
      (*i).print();
    // ...
  }

It would be clearer to write:

    for( vector<int>::iterator i = v.begin(); i != v.end(); ++i )
      i->print();

I know this may seem ambiguous since most people expect operator-> to
function only on pointer types, but my view is that iterators are safe
pointer wrappers and should be expected to act similarly.

What do you think?

-Kevin

--
----------->  Kevin Jacobs  <-----------|------->  (216) 778-8487  <--------
S.A.G.E. Project Technical Coordinator  | Department of Epidemiology
  & System Administrator                |   & Biostatistics
Internet E-mail: jacobs@darwin.cwru.edu | Case Western Reserve University
----------------------------------------------------------------------------


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]