Hi Vicente, On Aug 29, 2011, at 6:02 PM, Vicente J. Botet Escriba wrote:
Le 29/08/11 20:22, Gordon Woodhull a écrit :
I tried a number of approaches but only found one way that would work. This uses function overloading over an inheritance chain of converter classes, each of which brings its parent's convert() function(s) into scope with 'using'. Your design has several advantages over the one I use: it avoids ODR and allows multiple conversions on different domains. The user could even define a mixin that uses the intrinsic implicit/explicit conversions the C++ langage provides and include it in the set of possible overloads.
Thanks! It completely escapes ODR because a conversion domain is defined in terms of the individual conversions. In your library, what are the advantages/disadvantages of the two customization mechanisms, template specialization and function overloads? I guess the function overloads found through ADL have a nicer syntax, as shown in your example of a substitute for explicit conversions. It allows definition (as friend) within the class. But you list template specialization first, and that has the advantage of not having to take a dummy parameter. Are there other differences between the two techniques that would make one choose one or the other? I ask because I struggled to try to make template specialization over a hierarchy work in the 'domains' code I sent yesterday. But if function overloading is as good, I guess it's almost useable. Disadvantages of the 'domains' approach I can see: * metaprogramming = slower compile times (this compiles in less than a second but still..). I can see how to implement it more cheaply with variadics, also nicer syntax that way.. but not really an option unless with a macro wrapper. * details exposed in the converter interface: it's annoying to have to derive from a template parameter and then bring in overloads with 'using'. I don't see any way around this except with macros. If you look at how operations are defined in TypeErasure [1], you can see Steven is running into similar problems. Maybe some indecipherable boilerplate is unavoidable. * no default domain (so it's really not a substitute for overloadable static_cast anymore) And of course my mind goes to, isn't this really just a polymorphic function object? Can this be solved in one line with Phoenix? :-D
Vicente, have you considered similar approaches? Not exactly in this form and context. I have made an extension to Boost.Endian that make endian conversion depending on a domain parameter that maps each one of the leaves to its intended endiannes.Your converter maps, if I can say, each pair of source+target types to an overloaded convert function.
Yes, it is really the same as your approach, just generated using metaprogramming. Cheers, Gordon [1] http://lists.boost.org/Archives/boost/2006/08/108701.php