Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at