-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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