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-08-30 16:50:56

Le 30/08/11 20:43, Jeffrey Lee Hellrung, Jr. a écrit :
> On Mon, Aug 29, 2011 at 10:08 AM, Vicente J. Botet Escriba<
> vicente.botet_at_[hidden]>  wrote:
>
>> Le 29/08/11 18:07, Jeffrey Lee Hellrung, Jr. a écrit :
>>
> [...]
>
>> Vicente, if you have some real-world use cases that you know of, please
>>> share.
>>>
>>>   I removed the initial motivation from the documentation (it is a little
>> bit long). Here it is what I wrote:
>>
>>
>>
>> Let me know if this is enough real for you.
>>
> Your example of converting between boost::chrono objects and
> boost::posix_time objects is, indeed, a real use case, so thank you.  I can
> imagine other similar use cases, where you want objects from two independent
> libraries to be interconvertible.  But this isn't *quite* what I was looking
> for.  Have you (or do you know someone who has) used the framework provided
> by Boost.Conversion to utilize conversions in a generic setting (e.g.,
> generic algorithms or data structures)?  If not or not so much, are we
> hoping that such algorithms and data structures will be created in the
> future?
>
> I'm feeling like I'm missing something here regarding the library's
> utility.  I admit I haven't gone though the documentation, but I think I
> have a general idea of what the library is trying to achieve immediately
> (provide extrinsic conversions between unrelated types).  What about beyond
> that immediate goal?  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.
> 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 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.

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.
> So my experience may be coloring my perceptions.
>
> I hope I don't sound too negative :/
>
>
Don't worry. I agree with all of you that the library has deep holes and 
that another design seems to be needed to cover with the generic 
conversions. I hope that someone else will make a proposal that will 
cover with.

Best,
Vicente