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 19:15:15

----- 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.  

How do you know the To to which do you want to convert, if not given explictly?

> 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?

I'm interested on seen how you have solved the problem you found. and please could you post your example and show why it can not be specialized with the proposed convert_to or assign_to interface? Non conforming use case will improve the final library.

> 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...?

The single think I can answer is that the same question is already on the documentation,  unfortuantley with no answer.
The answer I can give you now is that I don't master ADL to the point of using it to imlement what I have in mind. I'm unable to saying you if this is possible or not. The question of using partial specializations of template functions is for the moment secondary, if there is a better way to achieve the same goal. My  main concern is if we need the generic functions convert_to and assign_to. If this can be implemented in a better way using only ADL, we could do this way. Of course I'm intersted in knowing how this can be implemented using only ADL, even if this is evident for most of you.
 
> This is definitely a problem that needs to be solved (correctly) in a 
> generic fashion, so I'll try to follow your progress.

I'm open to any sugestion. If we can implement it using only ADL, I will do it once I'll know how.

BTW, can we add functions on the 'std' namespace?

Thanks for your comments and questions,
Vicente