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@wanadoo.fr> 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