Re: [boost] improved iterator traits/concepts

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-03-22 00:18:14

Hi John,

I just finished rewriting this proposal as a paper to the C++ LWG. Perhaps
it's current form is closer to what you'd like to see (the paper is
attached). I beleive your real iterators match up with my Mutable Lvalue
Iterator and Constant Lvalue Iterator concepts (when combined with one of
the traversal concepts), and your imaginary iterators match up with my
Readable Iterator (again when combined with a traversal concept).

I have not made a place for your negative imaginary numbers... is
there a real ;) reason to have these?

Cheers,
Jeremy

On Wed, 21 Mar 2001, John E. Potter wrote:
jpotte> 
jpotte> I understand your goals, but think that the fix does nothing.  Since
jpotte> Dave pointed out that there is no required relationship between
jpotte> iterator_traits reference/pointer and the return type of operators,
jpotte> they are totally broken anyway.
jpotte> 
jpotte> Let's pretend that they do work.
jpotte> 
jpotte> We have real iterators with value_type, reference, pointer being
jpotte> T, T&, T* and T& operator*, T* operator->, T& operator[].  Real
jpotte> iterators are in forward, bidirectional, random_access.  We also
jpotte> have fictious iterators in input, output.  Output iterators have
jpotte> value_type void and traits are worthless.  Istream and istreambuf
jpotte> iterators have value_type T and reference T&; however operator*
jpotte> returns T const& and T respectively.
jpotte> 
jpotte> Although the standard has been questioned, I have no problem with
jpotte> the negative real iterators (const_iterator).  Value_type,
jpotte> reference, pointer as T, T const&, T const* and T const& operator*,
jpotte> T const* operator->, T const& operator[].
jpotte> 
jpotte> The problem seems to be with iterators which can not return
jpotte> a reference.  That seems to be orthoginal to the real iterators; so,
jpotte> let's call them imaginary iterators (value_iterators).  Value_type,
jpotte> reference, pointer as T, T, ? and T operator*, ? operator->,
jpotte> T operator[].  Istreambuf solves the operator-> problem by not
jpotte> having one and having a useless pointer of charT*.  I don't think
jpotte> that is good enough for the imaginary iterators.  If (*it).m is
jpotte> valid, it->m should also be valid.
jpotte> 
jpotte> We can also have negative imaginary iterators with T and T const
jpotte> for those who like unmodifiable rvalues.
jpotte> 
jpotte> I think that the solution is to nail down the return types of the
jpotte> iterator operators as in the standard tables.  The traits can then
jpotte> be written to match them.
jpotte> 
jpotte> John
jpotte> 
jpotte> 
jpotte> List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
jpotte>  
jpotte> 
jpotte> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
jpotte> 
jpotte> 
jpotte> 

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate                  email: jsiek_at_[hidden]
 Univ. of Notre Dame         work phone: [phone]
----------------------------------------------------------------------