From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-11-20 14:44:28
Christopher Currie wrote:
> Peter Dimov wrote:
>> 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.
I'm not sure I understand. The failures that I see here:
http://boost.sourceforge.net/regression-logs/cs-SunOS-links.html#bind_test-sunpro
are not caused by the problem you reported, as bind_test.cpp does not test
the derived object case (only mem_fn_derived_test does). Apparently the Sun
compiler cannot handle pointers to data members well, selecting the general
overload instead. This would correspond to:
template<class F> void bind(F f);
template<class R, class T> void f(R T::* pm);
struct X { int i; };
int main() { f(&X::i); }
Unfortunately I don't have access to this compiler so I cannot test my
theory. ;-)
>> 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?
Yes it should, you have found two bugs in the compiler. ;-)
>> 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 don't think that we can do anything about the derived class issue.
mem_fn_derived_test.cpp will still fail, as it should, as the compiler
simply cannot handle the case.