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-31 02:03:54

Le 30/08/11 23:02, Vicente J. Botet Escriba a écrit :
> Le 30/08/11 22:30, Vicente J. Botet Escriba a écrit :
>> Le 30/08/11 20:33, Mathias Gaunard a écrit :
>>> On 30/08/2011 19:38, Vicente J. Botet Escriba wrote:
>>>
>>>> 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.
>>>
>>> Let's say I do a fusion sequence to string converter.
>>> Then I do a proto expression to string converter.
>>>
>>> (Proto expressions are also fusion sequences)
>>>
>> Your are right. This is a good example as it is not reasonable to 
>> make a specialization for fusion sequences that are no proto 
>> expressions. As any concept can be refined we need to use another 
>> technique than SFINAE to be able to specialize the refinement.
>>
>>
> Thinking about it a little but more, the library can take care of 
> concepte refiniment specialization defining some wrapping classes for 
> each concept. So we could have a fusion_sequence_wrapper and a 
> proto_expression_wrapper that inherits from fusion_sequence_wrapper.
>
> Now we can define conversion specializations for 
> fusion_sequence_wrapper<T> to string and fusion_sequence_wrapper<T> to 
> string without using SFINAE. Of course, it will be better if the user 
> didn't needed to wrap them explicitly.
>
P.S. There is a copy/paste typo in the last fusion_sequence_wrapper<T>. 
Please replace it by by proto_expression_wrapper<T>.

Hi,

I've found the motivation for the Dispatch library here 
(https://svn.boost.org/svn/boost/sandbox/SOC/2011/simd/libs/dispatch/doc/dispatch.qbk). 
IIUC my wrappers could provide a solution that is close to the 
tag-dispatching mechanism.

While the library present a generic framework that Boost.Conversion 
could use to avoid the SFINAE problem, it doesn't manage with the unique 
possible interpretation of the specialization. So I think your library 
could not be used in an open way where users can provide specializations 
and in this case SFINAE could be able to resolve the conflic as know all 
the specialized cases. Am I missing something? How Boost.Dispacth manage 
with this issue?

What I mean is that any concept that could be mapped by the user, could 
be mapped by independent libraries that will be incompatible for a end 
user due to ODR violation signaled for Boost.Conversion. My question is, 
does it means that the library is not useful?

Thanks for working on a general dispatch library,
Vicente