[range] why not range_result_iterator remove_cv?

Hi, I think non-intrusive customization way needs four specializations; 'X', 'const X', 'volatile X' and 'const volatile X'. At last, twenty specializations are required for five metafunctions. I view that's something like the pitfall of public virtual interfaces. Only range_result_iterator happens to work around by using remove_cv. See: I added followings to <libs/range/doc/example.cpp>: template< class Range > typename boost::range_result_iterator<Range>::type my_begin(Range& rng) { return boost::begin(rng); } // then... my_begin(cpair); // error Why not something like: template< class T > struct range_result_iterator : mpl::eval_if< is_const<T>, range_const_iterator< typename remove_cv<T>::type >, range_iterator< typename remove_cv<T>::type > > { }; Regards, MB p-stade.sourceforge.net

MB wrote:
Hi,
I think non-intrusive customization way needs four specializations; 'X', 'const X', 'volatile X' and 'const volatile X'. At last, twenty specializations are required for five metafunctions. I view that's something like the pitfall of public virtual interfaces.
if that is true, then it is certainly bad.
Only range_result_iterator happens to work around by using remove_cv.
See:
I added followings to <libs/range/doc/example.cpp>:
template< class Range > typename boost::range_result_iterator<Range>::type my_begin(Range& rng) { return boost::begin(rng); }
// then... my_begin(cpair); // error
right, because we instantiate range_const_iterator< const T >, which should never happen.
Why not something like:
template< class T > struct range_result_iterator : mpl::eval_if< is_const<T>, range_const_iterator< typename remove_cv<T>::type >, range_iterator< typename remove_cv<T>::type > > { };
Seems right to me. I the latest release I actually added similar stuff to begin(),end() to remove const qualifiers from "const T", since it lead to such "const T" being used to instatiate metafunctions *even though* the overload was never picked. So this means that begin()/end() must also remove volatile. Cute :-) Thanks for the feedback -Thorsten

Thorsten Ottosen wrote:
MB wrote:
Hi,
I think non-intrusive customization way needs four specializations; 'X', 'const X', 'volatile X' and 'const volatile X'. At last, twenty specializations are required for five metafunctions. I view that's something like the pitfall of public virtual interfaces.
if that is true, then it is certainly bad.
Only range_result_iterator happens to work around by using remove_cv.
See:
I added followings to <libs/range/doc/example.cpp>:
template< class Range > typename boost::range_result_iterator<Range>::type my_begin(Range& rng) { return boost::begin(rng); }
// then... my_begin(cpair); // error
right, because we instantiate range_const_iterator< const T >, which should never happen.
Why not something like:
template< class T > struct range_result_iterator : mpl::eval_if< is_const<T>, range_const_iterator< typename remove_cv<T>::type >, range_iterator< typename remove_cv<T>::type > > { };
Seems right to me.
I the latest release I actually added similar stuff to begin(),end() to remove const qualifiers from "const T", since it lead to such "const T" being used to instatiate metafunctions *even though* the overload was never picked.
So this means that begin()/end() must also remove volatile. Cute :-)
Thanks for the feedback
-Thorsten
I show my current private patch: namespace boost { namespace range_detail { template< class T > struct remove_cv_ : #if !BOOST_WORKAROUND(BOOST_MSVC, == 1310) remove_cv<T> #else mpl::eval_if< is_array<T>, // is_const is broken if array remove_volatile<T>, remove_cv<T> > #endif { }; } // namespace range_detail ////////////////////////////////////////////////////////////////////////// // default ////////////////////////////////////////////////////////////////////////// template< class T > struct range_result_iterator : mpl::eval_if< is_const<T>, range_const_iterator< typename range_detail::remove_cv_<T>::type >, range_iterator< typename range_detail::remove_cv_<T>::type > > { }; } // namespace boost But I guess this is not portable for broken compilers, though eVC4, VC7.1, VC8 and GCC3.4 seem to work. All I can say is "Be careful about 'boost::is_const'." :-) Regards, MB p-stade.sourceforge.net
participants (2)
-
MB
-
Thorsten Ottosen