[boost] Re: Template deduction problems on Sun (possible new/updatedconfigtest?)

From: Christopher Currie (christopher_at_[hidden])
Date: 2003-11-20 14:23:26

Peter Dimov wrote:
>>The Sun compiler has no problem with the first foo() call, but fails
>>to compile the second. Curiously, if I add this declaration:
>>
>>template < typename T > void foo( T );
>>
>>making the function definition a partial specialization, it compiles
>>without difficulty.
> 
> This affects bind_test, right?

That's correct. The reason I suggested the template ordering macro is 
that it's used in the Bind sources as a workaround, and that enabling it 
fixes bind_test, although I suspect it may reduce functionality in other 
areas I'm not aware of.

> The problem above is not related to function template ordering; your
> original example has a single function template, so no ordering is done. The
> revised example can be viewed as an ordering issue, even though it's not.

Is there a good description for what this problem is? Your correction of 
my misunderstanding of the function's type lead me to try

        foo( static_cast<int(B::*)()>(&X::f0) );

which also allows the test case to compile, so perhaps the problem is 
not with templates at all, but with the compiler's type deduction? The 
expression:

        std::cerr << typeid( &X::f0 ).name() << std::endl;

emits "int(X::*)()", which is why I was misunderstood. Granted the 
result of std::typeinfo::name() is platform-specific, but it does give 
us an idea as to what is going on. However, even the expression:

        assert( typeid( &X::f0 ) == typeid( int(X::*)() ) )

which, if I understand correctly, should cause the program to assert, is 
run without complaint. So even if the compiler is getting type of the 
expression wrong, shouldn't it be able to find the right template instance?

> But even if we did have a macro for this case, what could we possibly do
> with it?

Well, for starters, it could be used to improve the support for Bind on 
the Sun compiler, and might also be necessary to devise other 
workarounds for it. I understand the reluctance to invent yet another 
BOOST_NO_* macro, particularly if it's just for a single compiler, but 
I'm reluctant to suggest using BOOST_WORKAROUND instead, since it isn't 
a good description of the problem.

Having a workaround macro, on the other hand, and a test case in 
config/test to go with it, at least a) documents the issue, b) would 
alert us if there are other compilers with the same problem lurking 
around, and c) would let us know the as soon as the problem is fixed and 
the macro isn't needed anymore.

I'm willing to go either way, though, and I appreciate you taking the 
time to comment.

Christopher