|
Boost : |
From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-11-19 17:04:40
Hi John,
sorry for jumping into this discussion. It's because ...
John Maddock wrote:
> So... the question might be, why not a remove_member_pointer trait that
> converts:
>
> T (U::*) to T
>
> except that no one seems to have thought of let alone needed such a beast
> until now.
... I certainly have thought of such a beast, but as you probably know, ...
>
> So.... the follow up question might be, since your code has to handle
> member-function-pointers differently from regular function-pointers, why not
> change:
>
> template <class T>
> void f(T f)
> {
> typedef function_traits<typename remove_pointer<T>::type> ft;
> // use ft here...
> }
>
> to
>
> template <class T, class U>
> void f(T (U::*))
> {
> typedef function_traits<T> ft;
> // use ft here, T is deduced as a function type
> }
>
... we currently can't really make code like this work reliably, because:
- if the member function is cv-qualified the program is ill-formed by the current Standard
- if you put U and T back together (e.g. for passing the argument on) the type might be incompatible with the type of the argument (this scenario occurs if cv qualification is silently dropped or when MSVC's thiscall silently becomes cdecl - it happens with the default configuration of this compiler)
- some compilers (GCC, maybe others) will find the function template's signature doesn't match a pointer to member function (same problem with template partial specialization)
>
> To conclude, how should this best be handled?
>
Brute force, I guess ;-). IOW the proposed FunctionTypes lib or something similar.
Regards,
Tobias
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk