[cfe-dev] (Unexpected) Method type

Douglas Gregor dgregor at apple.com
Mon Jan 11 07:51:30 PST 2010

On Jan 10, 2010, at 12:44 PM, Sebastian Redl wrote:

> Abramo Bagnara wrote:
>> Il 10/01/2010 16:07, Sebastian Redl ha scritto:
>>> It's deliberate. I saw no reason to give it a distinct type. A
>>> MemberPointerType to FunctionProtoType is a pointer to member function.
>>> The only place where a member function can appear without a pointer to
>>> it is in call expressions. You can't do anything with the function in
>>> these cases except call it, so the type system gets along just fine.
>>> The bug here is that the validation code for & takes a wrong path and
>>> returns a normal PointerType to FunctionProtoType.
>> To tell you the truth, I'm a bit perplexed: I think that a non static
>> method type is something very different from an ordinary function type
>> and that they should not share the same type.
> But they do! Look at this snippet; GCC accepts it:
> typedef void FuncType();
> FuncType func; // Declare a normal function called func, no return value
> or parameters.
> void func() { // Define func.
> }
> struct A {
>  FuncType mfunc; // Declare a member function called mfunc, no return
> value or parameters.
> };
> void A::mfunc() { // Define mfunc.
> }

Template argument deduction is another place where we see that the type of a member function is just a normal function type, since a pointer to member function is really just a pointer to member where the member has function type:

  template<typename T> struct X;
  template<typename T, typename Class> struct X<T Class::*> { };

  struct Y { };

  X<int (Y::*)(int)> x; // instantiates partial specialization with Class=Y, T=int(int).

  - Doug

More information about the cfe-dev mailing list