Re: [boost] type_traits question

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-09 08:10:35

----- Original Message -----
From: "John Maddock" <John_Maddock_at_[hidden]>

>
> >Are you complaining about my word order? I could have written "pointer to
> >member function" instead. Still, I can't detect one with type_traits if
> I'm
> >not mistaken.
>
> No, I'm typing more words than I intended - I should have said: you can't
> dereference a member pointer, so there are no
>  references to member pointers, or types "member function".  There are
> obviously pointers to member functions, and as you say you can't separate
> them from other pointers to members using the current type traits -
> something that may well be considered a defect.

Would you mind adding it? You have all the infrastructure there already.

> BTW it's interesting that
> you *can* separate "pointers to objects" from "pointers to functions"

I presume you mean "without partial specialization". You could always write:

is_pointer<T> && is_function<remove_pointer<T> >

> using
> (in pseudocode):
>
> is_object_pointer<T> = is_pointer<T> && is_convertible<T, const volatile
> void*>
> is_function_pointer<T> = is_pointer<T> && ! is_convertible<T, const
> volatile void*>

Hmm, yeah.

It really seems like giving the user a lot of hoops to jump through, though.
Just because a "real compiler" has partial specialization and you can build
some of these things from primitives doesn't mean we shouldn't provide
things like is_function_pointer directly. I'm thinking of other compound
traits like is_reference_to_const, for example. A reference to const has
fundamentally important properties in the language.

Given that type_traits is one of the best ways to work around the lack of
partial specialization, it also helps those less fortunate... ;-)

-Dave