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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-07 03:11:25

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger

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

I disagree.  The type of a member function is a regular function type.  Note
that type equivalence does not imply functional equivalence (i.e. how it works).
The notion of 'type' is only a conceptual abstraction.  Regardless, the type of
a member function is a regular function type, even though the type of a
pointer-to-member-function differs significantly from a pointer-to-function.

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

Should be a parse error on any compiler.

typedef int x(int) const; // correct

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

I understand (though don't entirely agree with) your motivation for this.  There
isn't much you can do with cv-qualified function types, and there are a load of
gray areas (even in the standard).  Another fun one is exception specifications.

> > 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::*)() ).

I know.  For the record, however, both GCC and MSVC are wrong.  It should match
the specialization and the result should be 'void ()'.

> The fact that there can be calling conventions particular to 
> member-functions 
> makes these "add/remove member pointer transformations" even 
> more troublesome.

It is particularly annoying that there's a separate calling convention for this.
It is totally unnecessary.  I'd be more than happy if we could get rid of the
inferior __stdcall calling convention also.  Note also that calling convention
is properly in the domain of "extra-linguistic instructions to the compiler" and
should be implemented with pragmas.  This is especially true if C++ picks up
C99's _Pragma operator which can be the result of a macro expansion.  E.g.

#define __stdcall _Pragma("__stdcall")

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

That's fine with me.  I only really commented to point out that there is no
"member function type" as a distinct entity.  I don't think that 'nonmember' is
a property of a function type--it just doesn't make sense.

Regards,
Paul Mensonides