Re: [boost] Re: Member function detection: VC7.1 workaround needed

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++

 >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.