Jonathan Turkanis wrote:
Thanks for your effort coming up with this workaround. Unfortunately, although it works okay (when modified as described below) in isolation, when it is generated by macros as a deeply nested template, something goes wrong and it doesn't handle overloading.
Coud you pls. send me code to reproduce problem? I will try to find a fix.
1. I believe it is non-conforming, since explicitly specifying the template argument Type should suppress template argument deduction and therefore SFINAE. But this is irrelevant for a broken-compiler workaround.
I'm pretty sure that you are wrong. There are *two* template functions taking single type parameter, thus explicit specification of template arguments just "limits" overload set to these two templates. But still, there is some overload set. Selection is performed by partial ordering of template functions, as type of only parameter of one of them is valid only for type satisfying our requirements. Just to confirm this, see results of the same program on Comeau 4.3.3 and GCC 3.4.2:
como --a T543.cpp -oT543 Comeau C/C++ 4.3.3 (Jan 13 2004 11:29:09) for MS_WINDOWS_x86 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict warnings C++
T543 1 0 0 0 0 1
g++ -W -Wall --pedantic-errors --ansi T543.cpp -oT543
T543 1 0 0 0 0 1
2. It's necessary to verify that the main template parameter Type is a class type before using the expression char (Type::*)(int, float) as a template parameter. But this is easy using is_class.
Right. Otherwise hard to understand compilation error may happen. B.