Re: [boost] [review] Conversion review ends today

Subject: Re: [boost] [review] Conversion review ends today
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-01 02:38:34

Le 01/09/11 00:28, Jeffrey Lee Hellrung, Jr. a écrit :
> On Wed, Aug 31, 2011 at 11:55 AM, Gordon Woodhull<gordon_at_[hidden]>wrote:
>
>> Hi Jeff, Vicente,
>>
>> On Aug 30, 2011, at 4:50 PM, Vicente J. Botet Escriba wrote:
>>> 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
>> 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.
>
>>> I initially constructed a generic framework
>>>> similar to that defined by Boost.Conversion, but ultimately I discarded
>> 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