Metrowerks::is_pointer has a much simpler implementation.
Compiler specific versions always do, I really wish we could have a clean Boost version, loud sigh etc, etc....
We should probably be forwarding to the metrowerks implementation on 9.4, where it's available. Failing that we can check is_class first and avoid the rest of the check in that case.
I must be missing something. The trivial implementation of is_pointer:
template<class T> struct is_pointer: mpl::false_ {}; template<class T> struct is_pointer<T*>: mpl::true_ {};
should work on everything except MSVC 6/7, right? So why isn't it being used?
Yeah, duh. Why not?
Lots of reasons, but as usual it's complex: 1) There are some compilers that bind member [function] pointers to foo<T*> partial specialisations, if I remember correctly, gcc was one, but don't quote me on that, and I don't know which behaviours are right and which wrong either. The fix was to check that a pointer was not a member pointer before actually declaring it a pointer. 2) is_member_pointer is a lot more complex than it really needs to be, but again it's workarounds that cause the problem: some compilers bind pointers to member functions to a foo<T (U::*)> partial specialisation, and others do not. I believe they all should bind to this partial specialisation, but that's a whole other argument. Anyway the fix was to check that a type was a member function pointer, as well as the "generic" partial specialisation. 3) There was a recent support request to recognise __stdcall, __fastcall, __cdecl etc function types as member function pointers and function types (in is_function and is_member_function_pointer). Sadly, no compiler I've tried allows you to write a partial specialisation based on function call type, where as function overloads based on function call types do work. For this reason windows compilers that support different calling conventions use the old "pass to an overloaded function" workaround for is_member_function_pointer and is_function. Frankly it all sucks, but it does mostly all work as well: probably better and with less maintenance than a pre-processor config based version would (the pre-processor logic is already too complex IMO). It's also possible that MWCW doesn't need any of the three workarounds above (if so it's in a minority of one). So what to do? Right now I'm thinking it's too close to release to do anything, but the easiest fix would be to change the function overload versions to not use ellipsis, I believe this is reasonably easy to do in this case, but haven't tested it, so knowing how these things usually go it probably won't work! :-) John.