Re: cycle_iterator

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-02-19 14:15:11

--- In boost_at_y..., Thomas Witt <witt_at_i...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 19 February 2002 07:09, rogeeff wrote:
> > --- In boost_at_y..., Thomas Witt <witt_at_i...> wrote:
> > > Gennadiy
> >
> > [...]
> >
> > > The main changes are:
> > >
> > > Added a const here and there.
> >
> > The only placewhere I would agree to put const in constructor: 
const&
> > instead of value. You can't make class data members const.
> > First of
> > all it prevent implementing mutable iterators and second you can't
> > even assign const iterator.
> 
> I think you misinterpret the const here. Iterators are just values, 
they have 
> pointer semantic but they are values. As a result const iterator 
and 
> const_iterator are fundamentally different. A const iterator is the 
same as 
> *const whereas a const_iterator is the same as const*.
> 
> Copying a const iterator to an iterator works just as copying a 
const double 
> to a double. You even can assign to the value pointed to by an 
const 
> iterator.
> 
> Making an iterator const means fixing its position and thats 
exactly what is 
> needed here. The range boundaries should be immutable for an 
cycle_iterator.

Sorry it was late and I did mix two independent issues here. My first 
point was irrelevant. But still you can't make Policies class member 
const because you can't implement operator= for iterator_adaptor. 
MSVC does not compile it and so would I on it's place. If you have 
 T const member;
in class definition, class became noncopyable. Am I wrong?

> 
> > Also I do not see any paractical reasons
> > in defining local veriables in 2 line inline function const. Do 
you?
> 
> I would not see not making them const as a fundamental error but 
they are 
> const so they should be made const. Removing the const here would 
be an 
> error.

Both having/missing const here are not an error, but rather matter of 
preferrence since compilers generate the same code. I would not put 
it here cause it is inconsistent with other boost headers. I never 
saw const qualifiers on local "const" variables. But I am open to any 
solution.

> 
> >
> > > Added make_cycle_iterator with iterator position (+ only works 
for random access iterators). What do you think about the interface.
> 
> > I do not think you need this ability in a real life for cycle
> > iterator.
> 
> Honestly, I _do_.

Could you provide an example?. The interface seems reasonable.

> 
> >
> > > Removed make_cycle with container argument.
> >
> > I think creating cycle iterator for container would be the most
> > frequently used feature. But we can't pass container by value. So 
we
> > need to choose between const/mutable reference. After some
> > consideration I would probably choose const version now.
> >
> 
> To me make_cycle with container argument is a covenience function. 
It can be 
> provided in addtion to a pure iterator function but not as a 
replacement. 
> First all std interfaces use iterators and so should 
cycle_iterator. Second 
> cycle_iterators should not be reduced to containers. They can be 
used and are 
> usefull with every valid range.
> 
> In my oppinion make_cycle with container argument should be removed 
as long as 
> there is no solution that covers both const and non-const 
containers. 
> Otherwise we would only confuse the users.

It is an addition. But after some consideration I think the 
difference is not that critical to justify addition function. So I 
agree with you.

> 
> Thomas
> 
> > [...]
> >
> > > Thomas
> >
> > Gennadiy

> Dipl.-Ing. Thomas Witt

Gennadiy.