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

Subject: Re: [boost] [review] Conversion review ends today
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-08-31 18:28:07

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 :)

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.

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

- Jeff