David Abrahams wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> 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? (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. -Thorsten