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. Vicente