Boost logo

Boost :

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! :-)


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