Tobias Schwinger wrote:
Paul Mensonides wrote:
-----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.
It's essentially saying the same thing, but I got your nuance: whether member or nonmember has nothing to do with the function type and only with the result type of operator& (or function-to-pointer conversion) applied an entity of that type.
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
Yeah, right -- actually I know -- just posted too quickly (shame on me). Still doesn't compile with GCC, though ("invalid specifier").
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.
In more detail: Given a compiler allows CV-qualified functions, these types pass the library without problems; the library detects them properly because top-level cv-qulification is ignored. There is no way to emphasize a query or specification for the cv-qualification of nonmember callable builtin types, which would involve adding overhead for an esoteric and unportable feature.
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 ()'.
That's what I meant; I should've added "EDG and Borland do it right".
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")
C99's _Pragma seems pretty close to GCC's "__attribute__(whatever)"...
Because of your awesome Boost.Preprocessor, my library does not have to worry about this sort of changes at all (its just a tuple element in the configuration) ;-).
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.
I use the terms "callable scalar type" (pointer/reference/member pointer to function) and "callable builtin type" (like "callable scalar" but includes function types) in identifier names which involve 'nonmember'.
The term "member" is only used in combination with "function pointer" and within the property tags "const_member" and "volatile_member" ("member" indicates they are ignored for any non-member-function-pointer). ^^^^^^^^^^^^^^^^^^^^ Should be non-member-function-pointer-callable-builtin-type (and I won't use such a term in the documentation :-) ).
Thanks for your reply which made me clarify my post.
Regards,
Tobias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost