Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
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?
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