Thorsten Ottosen wrote:
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.
I guess the same tragedy has already been happening in Boost.Serialization.
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)
Maybe that is the solution. Not bad.
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?
I would be glad to write something like 'ranges::make_mfc_range' which use private customization framework for 13 collections and 4 strings. Thus, Boost.Range itself doesn't use its public customization way. Something unfair! :-) FWIW, I have already written such framework, which might send feedback someday. -- Regards, Shunsuke Sogame