Re: Frasncis Glassboro wrote.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 11:35 PM, Paul wrote:
"Garrett Hartshaw" <ghartshaw@gmail.com> wrote in message
news:ig8jo6$age$1@speranza.aioe.org...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 08:55 PM, Paul wrote:
"Garrett Hartshaw" <ghartshaw@gmail.com> wrote in message
news:ig855p$ec1$1@speranza.aioe.org...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 02:06 PM, Paul wrote:
"James Kanze" <james.kanze@gmail.com> wrote in message
news:7148a492-1586-4421-bc6c-4afa38770f53@w29g2000vba.googlegroups.com...
On Jan 7, 2:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
[...]
I can understand the concept you express but
a) how do you get the address of a member function?
&ClassName::functionName
Concretely:
struct C { void f(); };
void (C::*pf)() = &C::f;
b) what happens if this member function is virtual?
It works correctly. That's why pointer to member functions are
often larger than any other pointer types (but there are other
ways of solving the problem).
What would your pointer point to ?
That's the compiler writers problem, not mine:-).
It certainly is a problem for the compiler, and perhaps the program
too.
Especially if you didn't initialised the empty pointer.
Let me put it another way, where would you get the address for the
virtual function?
You cannot do this with virtual functions and you are wrong
to suggest it works correctly.
It does work, and I've done it. More than once.
It simply can't be done as the concept of virtual functions only lives
in the world of objects.
Please show some basic code. I guarantee you cannot.
#include <iostream>
class C1 {
public:
virtual void f() {
std::cout << "C1::f" << std::endl;
}
};
class C2 : public C1 {
public:
virtual void f() {
std::cout << "C2::f" << std::endl;
}
};
int main () {
void (C1::*p)() = &C1::f; //create a pointer to a member function
C1 a; //create a object of type C1
C1 * b; //create a object of type pointer to C1
The challenge put forward was to invoke a virtual function without
creating an object. Here you have created an object.
I applaud your abilities nonetheless, assuming the code is correct.
b = new C2(); //allocate a object of type C2
(a.*p)(); //call the member function pointed to
//by p, with &a as this
(b->*p)(); //call the member function pointed to
//by p (virtually), with b as this
return 0;
}
This code prints the following.
C1::f
C2::f
The very nature of virtual functions require objects and perhaps you
have demostrated this.
This was what i was referring when I initially stated 'it won't work
with virtual functions':
"You can take the address of a member function (and assign it to a
function pointer of the proper type), and it will *not* be tied to any
specific object."
The (virtual) member function was *not* tied to a specific object, as it
(the same function) was used by two different objects. If it was *a part
of* the object, you would not be able to have a pointer to it.
With:
(a.*p)(); //call the member function pointed to by p, with &a as this
(b->*p)(); //call the member function pointed to by p (virtually),
with b as this
There are two functions here.
As I understand it you seem to think there is only one function . ????
Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object). However, if we had another object of (dynamic) type C2
(e.g. C1 * c = new C2(); ), and call the function ( (c->*p)(); ), then
we have 3 objects ( a, b, c ), and only 2 functions ( C1::f, and C2::f
). This would not be possible if the function itself was part of the object.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNJ/FsAAoJEO0SzzQOdchNkDAP/1Grv4JS8ytSK9QwAC5LYzRg
rAIIUWTmqfffisXZDP4URiJ6tXxu2FPcBtibr11q3s1xj96EKU08Wq3HsejeIsxk
r85Zu4WFIg1mo9VbOCd89Dqmt1TH1nqV1jyNB3H2Bj3fl5ZffAY0oIpwRSs1rRQi
dh2qurUz0ZLe3YY3Md4GNXqKqlBHH0eJm6Hagp6pzuqsRLNmCyxXFU8bxNzZJ3iX
eMAnZuLPMoKgK88LKx4h48eAp12HU1E1YZ9ycEeRp9Id/EFo3Ia1os5VGTacVHjw
tA7bZl/FDJEq21KCrRP7CZzdPLY6VIqzmN5EB6LprFfDE+7NDR2V+AxJ7P7KX9DR
3G+Tml/K2IPu7rhKc2Of4JlTfpFtBO22vX10g3GxmfIqKZpyeCyuug7CaaR+1DYI
ZcxxdnQLiFB7M6npTlLg8GiXNwO5DBXDMPcV8U9ZqEw0DJ/chOcLJxfnFR5/4RfQ
lufFSTI1vdpUlck4F7+wvPkJAHnWeNXW33DSYjlznMH8MbI4a5TkzhK1SnoK31rb
CVSizXZqo0j85cb3NxDTIA7nU+A4Zi5JAyBkeT0So1ThwmtgVIKwUTWCUz7c/8kU
Yz2IOHschxQtm2b8BUu4HoHPoVWcbpO3lWQflHKTHSZNm8l8hz8GSF0rGDIZxjXi
51WvaYzdoWQSJfrBNkNM
=d/p5
-----END PGP SIGNATURE-----