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/disp...). 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