Re: [boost] [conversion] conversion domains

Subject: Re: [boost] [conversion] conversion domains
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-29 18:02:32

Le 29/08/11 20:22, Gordon Woodhull a écrit :
> Hi Vicente, all,
>
> I've been thinking a bit about Conversion's ODR problems and the annoyance of headers that customize something globally (using e.g. template specialization) when they are included.
Yes, this is a big annoyance.
> I think I would prefer a design that allowed to define sets of conversions, or conversion domains.  When creating a converter, you would specify the list of conversions which you want.  That way a conversion domain is specified in one place, and not because you #include something.  Of course it also means there's no default domain, for better or worse.
>
> 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.
> Yes, it is requires ugly, specific code to define a converter (and mpl::quoting the converters when specifying the domain yuk), and I wonder if anyone could find a better way to do this.
I guess that the interface can be improved (e.g. the one used in the 
proposed library Boost.TypeErasure) so all the metafunction is not 
pressent at the user side, so it could be more friendly.
>
> (I would prefer if it were possible to use partial specialization of template classes, but I guess there is no way to combine specializations of a nested template using inheritance, and it invokes a weird bug in gcc [1] if you try to do so.)
>
> 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.

I really think your design merits to be explored :)

Best,
Vicente