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:
> > 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,
> pointer semantic but they are values. As a result const iterator
> const_iterator are fundamentally different. A const iterator is the
> *const whereas a const_iterator is the same as const*.
> Copying a const iterator to an iterator works just as copying a
> to a double. You even can assign to the value pointed to by an
> 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
> const so they should be made const. Removing the const here would
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_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
> > Gennadiy
> Dipl.-Ing. Thomas Witt
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk