Le 01/09/11 00:28, Jeffrey Lee Hellrung, Jr. a écrit :
On Wed, Aug 31, 2011 at 11:55 AM, Gordon Woodhull<gordon@woodhull.com>wrote:
Hi Jeff, Vicente,
Le 30/08/11 20:43, Jeffrey Lee Hellrung, Jr. a écrit :
I, too, had an application that required unrelated types to be interconverted, and generic algorithms and data structures
On Aug 30, 2011, at 4:50 PM, Vicente J. Botet Escriba wrote: that
required these conversions. Maybe you can share theese use cases with us. +1
I was doing conversions between numeric types within a generic context. For some conversions, I needed some additional context (e.g., an allocator). I don't think this is directly relevant, but also sometimes the conversion wouldn't be possible, and that could only be determined at runtime, so I use optional<T>s.
similar to that defined by Boost.Conversion, but ultimately I discarded
I initially constructed a generic framework this
framework in favor of the conversions being handled by a function object with signature operator()(const Srce& srce, type_tag< Dest>) -> Dest, since the conversions required additional context than that given by the Srce object. This is the same signature Conversion uses, only it uses function overloading instead of function objects.
Yes. There aren't too many options :) Gordon, I added the function overloading after a Jeff's suggestion.
Jeff, what method did you use to glue together the various function objects
into one?
I'm not sure I understand. I have a single, well-contained family of function objects that do the conversions for me, but within the context of where these conversions are actually used, one could straightforwardly replace the family of types and the corresponding family of function objects used to effect conversions between said types.
This seems similar to the Gordon suggestion. While this approach could work on most of the cases, is not able to manage with different conversion for the same couple of Source/Target types but applied to different leaves.
It's up to the generic component on whether it supports multiple conversion implementations, but I would think this unlikely. However, I think it's certainly possible for different clients using the same generic component to want different conversion implementations for a given pair of types, and that point, Boost.Conversion's universally-defined conversion implementations become useless. One wants the conversion operation to be parametrized as well as the types involved in the conversion.
Yes, in this case it would be better to relay on specific converters/conversions.
The single way Boost.Conversion could take care of these specific cases and also concept refinement is to wrap the parameter with a specific class. But this could not be enough efficient and quite cumbersome. I don't really see the utility of wrapping parameters in a specific class in order to select a different conversion implementation...it seems much more straightforward for generic code that utilizes conversions to simple accept one or more function objects that effect the needed conversions.
I agree that for these cases it is more natural to accept a functor. Best, Vicente