Re: [boost] [Range] breaking update pending

From: Shunsuke Sogame (mb2act_at_[hidden])
Date: 2006-02-06 03:48:15

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