Re: [boost] Re: cycle_iterator

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

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

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

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

> [...]
>
> > Thomas
>
> Gennadiy
>
>
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- -- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8ciye0ds/gS3XsBoRAu8yAJ0RvTxwvx9viKNVE8qPOSI3AQ9xeACeL6GI
257WTUIiI01TV7TwuTpivcU=
=lTIi
-----END PGP SIGNATURE-----