Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-10 15:23:02


Thorsten Ottosen <thorsten.ottosen_at_[hidden]> writes:

> David Abrahams wrote:
>
> > Thorsten Ottosen <thorsten.ottosen_at_[hidden]> writes:
> >
> >
> >> In the new version, this is how range_iterator is defined:
> >>
> >> namespace boost
> >> {
> >> template< typename C >
> >> struct range_iterator
> >> {
> >> typedef BOOST_RANGE_DEDUCED_TYPENAME
> >> mpl::if_< BOOST_DEDUCED_TYPENAME is_const<C>::type,
> >> BOOST_DEDUCED_TYPENAME range_const_iterator<
> >> BOOST_DEDUCED_TYPENAME
> remove_const<C>::type >::type,
> >> BOOST_DEDUCED_TYPENAME
> range_mutable_iterator<C>::type >::
> >> type type;
> >> };
> >>
> >> } // namespace boost
> >
> >
> >
> > Well, I think the logic is probably right but I have to say the code
> > looks a lot more complex than it probably ought to.
>
>
> I think I can remove some partial specializations based on constness,
> like you suggested, eg.:
>
> template< class R >
> const_iterator<R const> : const_iterator<R>
> { };
>
> But besides that, what else do you think looks complicated?

Maybe it's just all the macros. BOOST_DEDUCED_TYPENAME should have
been renamed BOOST_TYPENAME years ago, but you're still using it way
more than I've ever found necessary to satisfy old compilers.

> (Constness has certainly been a major pain)
>
> > There are lots of
> > places where the current code could profit from refactoring; this
> > might be another such place. For example, if you make range_iterator
> > do the right thing always, (maybe) you could spell
> > range_const_iterator as follows:
> >
> > template <class T>
> > struct range_const_iterator
> > : range_iterator<T const>
> > {};
> >
> > It's just an example; you have to check it to make sure it works out.
> > Anyway, I suggest you look hard for simplifying refactorings before
> > you commit a big rewrite.
>
>
> I the new design, range_iterator depends on two other traits:
>
> - range_mutable_iterator
> - range_const_iterator
>
> your suggestion would make the design circular dependent.

Well of course I wasn't suggesting circularity.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk