Boost logo

Boost :

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

--- In boost_at_y..., Thomas Witt <witt_at_i...> wrote:
> 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:
> > 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
> 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
> iterator.
> Making an iterator const means fixing its position and thats
exactly what is
> needed here. The range boundaries should be immutable for an

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

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


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