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: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2009-10-23 16:07:23

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