Re: [boost] Re: [type_traits] is_pointer<noncopyable> failsonCodeWarrior 9.4

From: John Maddock (john_at_[hidden])
Date: 2005-05-24 00:33:12

>>>> 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.