Re: [boost] [review] conversion - Vladimir's comments

Subject: Re: [boost] [review] conversion - Vladimir's comments
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-30 13:38:00

Le 30/08/11 19:20, Mathias Gaunard a écrit :
> On 30/08/2011 17:44, Gordon Woodhull wrote:
>
>>> template<  class Target, class Source>
>>> Target explicit_convert_to( Source const&  u );
>
> From the descriptions I have read, it seems this library is 
> essentially those two lines.
>
> Why should two lines of basic and non-variable C++ code form a Boost 
> library?
>
Hmm, well a little bit more than these two lines ;-)
>
>>> does not really work on a bigger scale. That does indeed work for 
>>> *concrete* Target and Source types. However, when one tries to 
>>> generalize (partially specialize) for a range of similar types, then 
>>> I feel the framework easily falters. Namely, if I decide to 
>>> specialize the above for a range of related Target types (say, 
>>> string-related types) *and* separately specialize for a range of 
>>> related Source types. Then compilation will fail if these two 
>>> separate specializations happen to overlap for some Target-Source 
>>> pair. That is not an academic case but concrete issues I faced with 
>>> Convert. I'd expect it to be as relevant with Vicente's library.
>
> An interesting point. You could use SFINAE, but that doesn't scale and 
> requires all partial specializations to be mutually exclusive.
>
Right. This doesn't mean that you can not use the library with 
specializations that don't conflict. Some useful examples are given for 
some Boost and STL classes. The idea is that the source and target 
specialization are enough concrete to avoid the conflict. If you have an 
example of partial specialization that will conflict I could try to see 
how I would do it.

> I happen to have a library to solve the problem of specializing a 
> function template for a category of types with best-match selection.
>
> It's essentially a formalized way to define tag hierarchies and macros 
> to make n-ary tag dispatching transparent.
>
> It is what Boost.SIMD and NT2 use to manage their many specializations 
> for different types and extensions.
>
> It will be proposed to Boost as a library of its own, named 
> Boost.Dispatch.
> (sorry for hijacking the thread and advertising my stuff)
>
No problem. I will use Boost.Dispatch if it responds to my needs. BTW, 
where can I get the Boost.Dispatch documentation?

Best,
Vicente