Boost logo

Boost :

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

        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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at