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