Hi Jeff, Jeffrey Lee Hellrung, Jr.-2 wrote:
On Mon, May 30, 2011 at 1:51 PM, Vicente BOTET <vicente.botet@wanadoo.fr>wrote:
Hi,
I've tried to add a configuration point in Boost.Conversion via overloading and ADL, but while the internal call of the library can find them using a trick that adds a parameter that contains the type of the return type, the user is not able to find them without using the same this trick, but this is too dark to be natural for user code.
Next follows a simplified code of the problem. The following
namespace N { struct S{};
template (*typename T*) T fct1(S const& s) { return T(s); } template (*typename T*) void fct2(T &t, S const& s) { t=s; } }
void test () { N::S s1; N::S s2; fct2(s2, s1); s2=fct1(*N::S*)(s1); // (1) }
Results in a compile error in (1)
error: ‘fct1’ was not declared in this scope
Is it standard behavior that fct1 can not be found by ADL?
Thanks, Vicente
P.S. Please replace (* and *) by angle brackets.
AFAIK, this is standard behavior. Explicitly providing template parameters to a function call (as well as namespace qualification and putting the function name in parentheses) disables ADL.
Thanks for the information.
I don't think you can provide an extension framework for Boost.Conversion without the result type appearing somewhere in the customization function's function parameters.
I don't really view that as any "darker" than, say, using Boost.EnableIf, or any of a number of other TMP hacks...they are all constrained from a (perhaps) more ideal syntax and form by the constraints of the language.
There is something that is troubling me on the fact that the developer will customize the conversion function using overload and ADL, but that the user could not take advantage in a simple way of this overloading. Taking in account that Boost.Conversion needs already a customization point to take care of conversion of types in the standard library (using partial specialization) the addition of the customization point using overload doesn't make simpler the user code, neither the developers customizing the class, as it would need to choose between two customization points that doesn't make any difference. If no one find that the additional customization (via overloading) point add some benefit to the library, I will prefer to remove it (IIRC, Jeff you were the one that suggested it). This will have the advantage of making the library quite more simple without limiting his expression power. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/conversion-ADL-and-templates-tp3561641p35... Sent from the Boost - Dev mailing list archive at Nabble.com.