Re: [boost] [function types] New tag type logic [update]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-06 17:01:43

Hi Paul,

allow me to add a few annotations in regard to the library and its documentation.

Paul Mensonides wrote:
>>-----Original Message-----
>>From: boost-bounces_at_[hidden] 
>>[mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> 
> 
>>>Way.  We are not talking about the functions, we're talking about 
>>>their types.  In other words, the traits do not inspect individual 
>>>values of int (*)(int) -- they inspect the type int(*)(int) 
>>
>>itself.  I 
>>
>>>don't think there's any problem with calling int(*)(int) a 
>>
>>nonmember 
>>
>>>function pointer type.
>>
>>If you're thinking about whether the type is that of a static 
>>member function, then you won't be thinking that you should 
>>use "nonmember."
> 
> 
> Just to be pedantic, the types of member functions are regular function types
> also.  

To be even more pedantic: there are no types of member function types (there are 
only function types decorated with a pointer to member which as a whole are 
'compound non-function types'). But it seems I look at it the very same way:

    This library provides functionality to classify, decompose and synthesize
    function types and other compound types directly decorating a function type
    with a pointer, reference or member pointer.

(this is a cite from the very first sentence introducing the library - this 
revised version of the docs has not been posted yet, however)

> Furthermore, you *can* have cv-qualified function types, such as 'int
> (int) const'.  

While theoretically correct, things are too implementation-defined around here to 
rely on that you can do anything with cv-qualified function types (not decorated 
with a pointer to member, that is). E.g:

    typedef int(int) const x; // parse error with GCC

We shouldn't use types like this -- this is the reason why the library does not 
support them.

> The differences are that you cannot declare a non-member function
> with a cv-qualified function type and that the types of pointers to actual
> functions differ based on whether they are (non-static) member functions.  E.g.
> 
> typedef void func();
> 
> func f;
> 
> struct x {
> 	func f;
> };
> 
> &f -> void (*)()
> &x::f -> void (x::*)()
> 
> 
> Likewise:
> 
> template<class> struct remove_pointer_to_member;
> 
> template<class R, class C> struct remove_pointer_to_member {
>     typedef R type;
> };
> 
> remove_pointer_to_member< void (x::*)() >::type -> void ()

Yeah. For the protocol: this code won't work with GCC (doesn't match the 
specialization) or MSVC ( R is substituted with void __thiscall(x::*)() ).
The fact that there can be calling conventions particular to member-functions 
makes these "add/remove member pointer transformations" even more troublesome.

> 
> Basically, the argument between member and non-member doesn't apply to function
> types.  If, OTOH, you're really talking about pointers to functions and pointers
> to member functions, then a type difference becomes evident and there is a
> significant distinction.  In that case, the types are "pointers to function"
> (which is the type classification of a pointer to static member function) and
> "pointer to member function" (which is the type classification of a pointer to
> non-static member function).  I think it is a misuse of terminology to say "the
> type of a function" and really mean "the type of a pointer to function."

The review version of the library redefined and widened the term "function type" 
for that matter. I never really liked it and the boostified version will 
pedantically use the term "function type" as defined by the standard and will not 
refer to a function pointer as being a function type!

Regards,

Tobias