By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,159 Members | 913 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,159 IT Pros & Developers. It's quick & easy.

About the address of member function

P: n/a
class Test
{
double i;

public:
void fun(){}
void foo(void)
{
cout << "as";
}
};

int main()
{
Test t;
t.foo; // mean what?
Test::foo; // mean what?

cout << &Test::foo << endl; // output 1, why?
cout << &Test::fun << endl; // output 1, too, why?

return 0;
}

Jun 13 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Sharpdew wrote:
class Test
{
double i;

public:
void fun(){}
void foo(void)
{
cout << "as";
}
};

int main()
{
Test t;
t.foo; // mean what?
Test::foo; // mean what?
The last two expressions mean nothing. They are illegal. You can make a
call:

t.foo()

Or take the address of the function:

&Test::foo

cout << &Test::foo << endl; // output 1, why?
cout << &Test::fun << endl; // output 1, too, why?

return 0;
}


Pointer to members are not really memory address in the strict sense.
You can think of it as a relative address (to whatever instance of that
type.)

Therefore, pointer to member cannot be converted to a normal pointer,
say, void*. Therefore it is not outputted as a normal pointer.

If you are so interested in the bit sequence of these pseudo pointers
you can do a forced conversion using reinterpret_cast, like so:

int main()
{
typedef void (Test::*tf)(void);

tf p1 = &Test::foo;
tf p2 = &Test::fun;

cout << *reinterpret_cast<void**>(&p1) << endl;
cout << *reinterpret_cast<void**>(&p2) << endl;
}
Jun 13 '06 #2

P: n/a
I'm sure know all you said, but what I want to know is the semantics of
these style code, that is to say, how do the compiler deal with them?
benben 写道:
Sharpdew wrote:
class Test
{
double i;

public:
void fun(){}
void foo(void)
{
cout << "as";
}
};

int main()
{
Test t;
t.foo; // mean what?
Test::foo; // mean what?


The last two expressions mean nothing. They are illegal. You can make a
call:

t.foo()

Or take the address of the function:

&Test::foo

cout << &Test::foo << endl; // output 1, why?
cout << &Test::fun << endl; // output 1, too, why?

return 0;
}


Pointer to members are not really memory address in the strict sense.
You can think of it as a relative address (to whatever instance of that
type.)

Therefore, pointer to member cannot be converted to a normal pointer,
say, void*. Therefore it is not outputted as a normal pointer.

If you are so interested in the bit sequence of these pseudo pointers
you can do a forced conversion using reinterpret_cast, like so:

int main()
{
typedef void (Test::*tf)(void);

tf p1 = &Test::foo;
tf p2 = &Test::fun;

cout << *reinterpret_cast<void**>(&p1) << endl;
cout << *reinterpret_cast<void**>(&p2) << endl;
}


Jun 13 '06 #3

P: n/a
I'm sure to know all you said, but what I want to know is the semantics
of
these style code, that is to say, how does the compiler deal with them?

benben wrote:
Sharpdew wrote:
class Test
{
double i;

public:
void fun(){}
void foo(void)
{
cout << "as";
}
};

int main()
{
Test t;
t.foo; // mean what?
Test::foo; // mean what?


The last two expressions mean nothing. They are illegal. You can make a
call:

t.foo()

Or take the address of the function:

&Test::foo

cout << &Test::foo << endl; // output 1, why?
cout << &Test::fun << endl; // output 1, too, why?

return 0;
}


Pointer to members are not really memory address in the strict sense.
You can think of it as a relative address (to whatever instance of that
type.)

Therefore, pointer to member cannot be converted to a normal pointer,
say, void*. Therefore it is not outputted as a normal pointer.

If you are so interested in the bit sequence of these pseudo pointers
you can do a forced conversion using reinterpret_cast, like so:

int main()
{
typedef void (Test::*tf)(void);

tf p1 = &Test::foo;
tf p2 = &Test::fun;

cout << *reinterpret_cast<void**>(&p1) << endl;
cout << *reinterpret_cast<void**>(&p2) << endl;
}


Jun 13 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.