Re: [boost] [conversion] Motivation for two NEW generic conver_to and assign_to functions

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://lists.boost.org/mailman/listinfo.cgi/boost
>