Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2002-02-19 05:44:42

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

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.

> 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

> > Added make_cycle_iterator with iterator position (+ only works for
> random
> > access iterators). What do you think about the interface.
> Specifying three
> > iterators seemed to error prone to me.
> I do not like the idea by itself. Since you can't check that this
> iterator position is in a range it could be very dengerous.

I do not buy this one. With the same argument std::copy or any other std
algorithm should be banned.

> For
> example, surprisingly the following statement would be an infinite
> loop:
> v - some container
> std::copy( boost::make_cycle_iterator( v ),
> boost::make_cycle_iterator( v.end(), v ),
> std::ostream_iterator( std::cout, "" ) );

This one could be easisly diagnosed by an implementation. v.end is not a valid
base iterator position as it is not in the range. Checking for base == end as
a common error seems like a good idea to me.

> I do not think you need this ability in a real life for cycle
> iterator.

Honestly, I _do_.

> > 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.


> [...]
> > Thomas
> Gennadiy
> Info: Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to
- --
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


Boost list run by bdawes at, gregod at, cpdaniel at, john at