Shunsuke Sogame wrote:
Thorsten Ottosen wrote:
How will a different mechanism save you from provding specializations of alle the types you want to support?
I tried to write Boost.Range implementation of ATL/WTL collections. But I gave up. There are 13 classes.
Is that without counting typdefs like CString etc? That is a lot.
They form a simple hierarchy, but we cannot take advantage of it. Partial class template specialization ignores base/derived relationship.
right.
And "primary" range_detail::boost_range_begin(C&) eats all the derived classes.
yes, a wierd feature of the language that we have to lieve with.
Thus, I have to write 13 implementations.
maybe the easiest would be to write a function, say, make_mfc_range(), that returns an iterator_range<...> of some sort. Then on all range boundaries you just call make_mfc_range(mfc_rng). (well,not great, but at least something)
Now I see ADL customization way is blob. Type itself has another job, that is, implementation selector. Left the job to tag...
For example, std::pair range implementation could be simplified to something like:
namespace customization {
namespace std_pair_detail {
struct tag { };
} // namespace std_pair_detail
template< class T > struct tag< std::pair<T, T> > : boost::mpl::identity<std_pair_detail::tag> { };
template< class PairT > struct metafunctions<PairT, std_pair_detail::tag> { typedef typename PairT::first_type iterator; typedef iterator const_iterator; };
template< > struct functions<std_pair_detail::tag> { template< class PairT > typename boost::range_iterator<PairT>::type begin(PairT& p) { return p.first; }
template< class PairT > typename boost::range_iterator<PairT>::type end(PairT& p) { return p.second; } };
}
Now 'PairT' is almost concept. A type derived from std::pair<> specializes only tag<>.
that is clever.
Moreover, 'const' overloads disappear.
also clever.
(though such overloads also are possible.) Of course, default implementation can call 'boost_range_begin'. Compatibility holds.
I said range metafunctions were "public virtual interfaces". IMHO, next version should make them non-virtual.
I don't plan to add such customization, sorry. But Iød be happy to include your support for mfc with the library. Maybe you can get some help from the preprocessor? -Thorsten