From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-11-16 07:54:25
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++
>g++ -W -Wall --pedantic-errors --ansi T543.cpp -oT543
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk