>> ConceptGCC 4.1.1 alpha 5 tells me that a class does not meet the
>> requirements of an iterator concept, if it does not have an
>> operator->().

Howard Hinnant wrote:
> List of current standard iterator types that do not have operator->():
>
> back_insert_iterator
> front_insert_iterator
> insert_iterator
> ostream_iterator
> istreambuf_iterator
> ostreambuf_iterator
>
> Most of these are output iterators.

Thanks! I realize I was not completely accurate about ConceptGCC.  It does
*only* require operator->() for input iterators.  So I'll rephrase my question:
  Should any InputIterator have an operator->() in C++0x?

> But not istreambuf_iterator. :-\
> Oh, and then there's vector<bool>::iterator...  Yes we don't like it,
> but we aren't getting rid of it.  The very most we will do is rename it.

istreambuf_iterator is designed to have a built-in type as value type, right?
If so, the lack of operator->() makes sense to me for istreambuf_iterator.  For
the same reason, I can understand why vector<bool>::iterator would not have an
operator->().

Are string::iterator and string::const_iterator required to have an
operator->()?  And if so, why?

> There are no algorithms in <algorithm> that require operator->().

In C++0x, I guess they will require operator->(), even if they don't use it.

> Can this be solved with a concept map (insert proper term here if
> concept map isn't it) that supplies a default definition of operator->()
> if one isn't available, and which wouldn't be instantiated if not used?

How would you do a default definition of operator->()?  Please take a look at
the small example below.  Bar is intended to be an input iterator, pointing to
Foo objects.  The concept map InputIterator<Bar> should provide an operator->(),
but it cannot access Bar::private_ptr, and Bar::operator*() does not provide the
address of the current Foo object either.

  //////////////////////////////////////////////////////////////////////
  #include <concepts>  // Tested on ConceptGCC 4.1.1 alpha 5
  #include <iterator>
  #include <cassert>

  struct Foo {
    char data;
  };

  class Bar {
    Foo* private_ptr;
  public:
    typedef Foo value_type;
    typedef int difference_type;
    typedef const Foo* pointer;
    typedef const Foo& reference;

    explicit Bar(Foo* arg = 0)
    : private_ptr(arg) {
      }
    Foo operator*() const {
      return *private_ptr;
    }
    Bar& operator++() {
      ++private_ptr;
      return *this;
    }

    Bar operator++(int); // trivial implementation
    friend bool operator==(const Bar&, const Bar&); // trivial
    friend bool operator!=(const Bar&, const Bar&); // trivial
  };

  namespace std {
     concept_map InputIterator<Bar> {
      Bar::pointer operator->(const Bar & arg) {
        assert(false);
        return 0; // How to implement this one correctly...?
      }
    }
   }

  int main() {
    return 0;
  }
  //////////////////////////////////////////////////////////////////////

Bar has purposely hidden the pointer to its current Foo.  I'm afraid that
therefore it cannot be accepted as an input iterator...  Any suggestion?


David Abrahams wrote:
> According to the current iterator concept definitions, I believe
> you're right, in the sense that the semantics of operator-> is defined
> entirely in terms of member access on the value type.  If the
> value_type is not a UDT, operator-> is meaningless.

> None of the existing std:: algorithms require that value_type is a
> UDT, but that doesn't really matter.  Lots of code outside the
> standard depends on the current iterator concepts.

Okay, that makes sense to me.

> The C++98 iterator concepts are overburdened with redundancy
> (http://boost.org/libs/iterator/doc/facade-and-adaptor.html#motivation).

Thank you, very interesting!

> operator-> is one of those things which, if you want to be faithful to
> those concepts, you must represent in ConceptC++.  There's plenty of
> argument for stripping the iterator concepts down to something more
> manageable in C++0x, but if you leave out operator-> (or anything else
> that's redundant in the current concepts) then the new iterators will
> not necessarily be compatible with old code, because old code is free
> to use any bit of redundant interface it wants.  Catch-22

So given this Catch-22 situation, I guess you think that ConceptC++ should
require operator-> for a input iterator, if and only if its value type is a
class or a struct.  Right?


Kind regards,

  Niels

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

on Sat Mar 24 2007, noreply-AT-this.is.invalid (Niels Dekker - no return address) wrote:

>> operator-> is one of those things which, if you want to be faithful to
>> those concepts, you must represent in ConceptC++.  There's plenty of
>> argument for stripping the iterator concepts down to something more
>> manageable in C++0x, but if you leave out operator-> (or anything else
>> that's redundant in the current concepts) then the new iterators will
>> not necessarily be compatible with old code, because old code is free
>> to use any bit of redundant interface it wants.  Catch-22
>
> So given this Catch-22 situation, I guess you think that ConceptC++ should
> require operator-> for a input iterator, if and only if its value type is a
> class or a struct.  Right?

I honestly don't have an opinion.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

When concepts become part of the language, should a user-defined
iterator be required to always have an operator->()?

ConceptGCC 4.1.1 alpha 5 tells me that a class does not meet the
requirements of an iterator concept, if it does not have an
operator->().  As a consequence, such a class would not be allowed as
a template argument for an std algorithm that required iterators as
arguments.

It seems to me that an operator-> is not necessary if the value type
of the iterator does not have any members.  E.g., if the value type is
a built-in type.

But even if the value type *does* have members, will an std algorithm
ever need to call the operator->() of the iterator?

I discussed this issue recently with Douglas Gregor, but we could not
really come to a conclusion.  So your feedback is appreciated!

--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
C++ programmer at LKEB, Leiden University Medical Center

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

on Thu Mar 22 2007, noreply-AT-this.is.invalid (Niels Dekker - no return address) wrote:

> When concepts become part of the language, should a user-defined
> iterator be required to always have an operator->()?
>
> ConceptGCC 4.1.1 alpha 5 tells me that a class does not meet the
> requirements of an iterator concept, if it does not have an
> operator->().  As a consequence, such a class would not be allowed as
> a template argument for an std algorithm that required iterators as
> arguments.
>
> It seems to me that an operator-> is not necessary if the value type
> of the iterator does not have any members.  E.g., if the value type is
> a built-in type.

According to the current iterator concept definitions, I believe
you're right, in the sense that the semantics of operator-> is defined
entirely in terms of member access on the value type.  If the
value_type is not a UDT, operator-> is meaningless.

> But even if the value type *does* have members, will an std
> algorithm ever need to call the operator->() of the iterator?

None of the existing std:: algorithms require that value_type is a
UDT, but that doesn't really matter.  Lots of code outside the
standard depends on the current iterator concepts.

> I discussed this issue recently with Douglas Gregor, but we could not
> really come to a conclusion.  So your feedback is appreciated!

The C++98 iterator concepts are overburdened with redundancy
(http://boost.org/libs/iterator/doc/facade-and-adaptor.html#motivation).
operator-> is one of those things which, if you want to be faithful to
those concepts, you must represent in ConceptC++.  There's plenty of
argument for stripping the iterator concepts down to something more
manageable in C++0x, but if you leave out operator-> (or anything else
that's redundant in the current concepts) then the new iterators will
not necessarily be compatible with old code, because old code is free
to use any bit of redundant interface it wants.  Catch-22

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <4602F166.5EBB30AC@this.is.invalid>,
 noreply@this.is.invalid (Niels Dekker - no return address) wrote:

> When concepts become part of the language, should a user-defined
> iterator be required to always have an operator->()?
>
> ConceptGCC 4.1.1 alpha 5 tells me that a class does not meet the
> requirements of an iterator concept, if it does not have an
> operator->().  As a consequence, such a class would not be allowed as
> a template argument for an std algorithm that required iterators as
> arguments.
>
> It seems to me that an operator-> is not necessary if the value type
> of the iterator does not have any members.  E.g., if the value type is
> a built-in type.
>
> But even if the value type *does* have members, will an std algorithm
> ever need to call the operator->() of the iterator?
>
> I discussed this issue recently with Douglas Gregor, but we could not
> really come to a conclusion.  So your feedback is appreciated!

List of current standard iterator types that do not have operator->():

back_insert_iterator
front_insert_iterator
insert_iterator
ostream_iterator
istreambuf_iterator
ostreambuf_iterator

Most of these are output iterators.  But not istreambuf_iterator. :-\

Oh, and then there's vector<bool>::iterator...  Yes we don't like it,
but we aren't getting rid of it.  The very most we will do is rename it.

There are no algorithms in <algorithm> that require operator->().

Can this be solved with a concept map (insert proper term here if
concept map isn't it) that supplies a default definition of operator->()
if one isn't available, and which wouldn't be instantiated if not used?
(my concepts education is still quite weak)

-Howard

---
[ 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.comeaucomputing.com/csc/faq.html                      ]