vicente.botet wrote:
----- Original Message ----- From: "Jeffrey Hellrung" <jhellrung@ucla.edu> To: <boost@lists.boost.org> Sent: Friday,
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,
There's no such thing as a partial specialization of a function template. Only classes may be partially specialized. You can explicitly specialize a function template (i.e. give specific values for all of its template parameters); is that what you mean?
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.
To do what you want with ADL has two problems: 1. You would have to call convert_to without passing any template arguments, so the destination type would have to be deducible from the arguments. You can use something like the type_tag Jeff mentioned. 2. The conversion function from A to B would have to be defined in either the namespace of A or of B (or of something else involved, e.g. the type_tag). If converting between types both from libraries you are not writing it is unwise to declare functions in their namespaces. If the library author decides to add support in the future with the same name (something I guess you're hoping for, if this name convert_to becomes widespread) then it will clash with your definition. But even if you avoid polluting other people's namespaces you will suffer a similar problem if they add a convert_to overload doing the same thing as yours; you'll get an ambiguous function call where you're using it. Worse still is if two people add convert_to overloads in the same namespace between the same types in such a way that the compiler doesn't see them both and complain; then you have an ODR violation and risk undefined behaviour (but you'll probably get away with a linking error). Similar issues apply even if you don't use ADL. The only ways I see to reliably avoid these sorts of problems are: 1. Whenever you want a conversion function between two types, get the author of a library containing one to add it to that library (and make sure the author of the other one doesn't add it to his). I presume this is impractical. 2. Somehow tag all the overloads and uses of convert_to in one library with a type from that library such that they will never clash with overloads from other libraries. The tag can facilitate ADL too. (This is a different tag from the type_tag above). This will add notational inconvenience and make it harder to use convert_to generically (e.g. as in your std::pair example; it will only work if there are convert_to overloads for both types in the pair with the same tag).
BTW, can we add functions on the 'std' namespace?
No, you may not. John Bytheway