Subject: Re: [boost] [conversion] Motivation for two NEW generic conver_to and assign_to functions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-10-23 18:42:09
----- Original Message -----
From: "Jeffrey Hellrung" <jhellrung_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 23, 2009 10:07 PM
Subject: Re: [boost] [conversion] Motivation for two NEW generic conver_to and assign_to functions
>
> vicente.botet wrote:
>> Hi,
>>
>> I would like to share with you what motivated me to add two new free template functions convert_to<> and assign_to<> on the Boost.Conversion.
>>
> <snip>
>
> This is a problem I've run across, too, of which I just have a basic
> framework in place that relies on finding a "convert" overload via ADL.
> I might have to read your docs and consider migrating to your specific
> implementation ;)
>
> Two comments (for now):
>
> 1) It's not uncommon that conversion to a "To" type from a "From" type
> needs more information than just an instance of a From. One example
> would be when dynamic memory allocation is necessary to construct the To
> type, e.g., when converting from a boost::array to a std::vector. In my
> application, I have to "upgrade" (i.e., convert) extended-but-fixed
> precision floats (which are statically allocated) to arbitrary precision
> floats (which are dynamically allocated), and the allocator_type of the
> arbitrary precision float shouldn't generally be default-constructed.
> I've worked around this by requiring my generic convert function to take
> a ConvertPolicy parameter (defaulted to some empty struct
> null_convert_policy_t), whose interpretation is up to the particular
> overload chosen for the conversion. I wouldn't mind seeing a better
> system in place. Have you considered this situation?
>
> 2) Assuming I understand the Conversion library correctly, what are the
> advantages to using both overloading via ADL and function template
> specialization as opposed to just the former? I'm not familiar of any
> other free functions used in boost (or anywhere else, for that matter)
> that rely on (perhaps I should say "allow"?) function template
> specialization, so I'm wondering what the motivation and pros/cons are
> (cons other than compiler support). I would guess that function
> template specializations must reside in the same namespace as the
> primary template...?
>
> This is definitely a problem that needs to be solved (correctly) in a
> generic fashion, so I'll try to follow your progress.
>
> - Jeff
> _______________________________________________
> Unsubscribe & other changes: http://listarchives.boost.org/mailman/listinfo.cgi/boost
>