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:-).
> 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.
> A virtual function calling mechanism requires an object.
Using a pointer to a member requires an object. So?
> >> 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 ?
The pointer points to the member function.
> You cannot do this with virtual functions and you are wrong to suggest it > works correctly. > A virtual function calling mechanism requires an object.
It is required to work also with virtual member functions. To make this possible, you have to specify an object when dereferencing the pointer to a member function.
If I were to implement such pointers, they would consist of the following: - A flag indicating if dynamic dispatch (for virtual member functions) is needed or not, and - The address of the function, for non-virtual member functions, or - The offset in the vtable, for virtual functions.
<snip>
> >> And what exactly would 'this' point to?
> > The class object you used in the dereferencing expression.
> A class is not an object.
I will give you this nitpick.
To answer the question again: 'this' points to the object, of class type, that was used in the dereferencing expression.
> No object was ever declared in your code.
> Once again you appear confused about classes an objects.
To me, it appears more like careless writing.
<snip>
> If you intend using a function as a standalone function why would you define > it as a member function of an object type. This seems like bad program > design.
Who is talking about using member functions as stand-alone functions?
>> >> 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.
>> A virtual function calling mechanism requires an object.
> Using a pointer to a member requires an object. So?
> -- > James Kanze
The point was to show that a member function can be called *without * an object.
In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote:
>> I find it a bit ironic that you protest so loudly abour common concepts >> of C++ programming, yet you lack such knowledge of the language.
> The fact that you have began your posting with a direct insult to me
How exactly is it "a direct insult" for me to find your behavior ironic?
> leaves > me no other opinion than you are actually nothing more than an other > clueless idiot who has nothing more than an UNREASONABLE argument to put > forward.
What that makes me think is that you are playing the "you insulted me" card in order to get yourself out of having to actually answer the objections presented to your claims.
Perhaps if instead of playing that card you would actually demonstrate how what I wrote is wrong, we could have a conversation. If you won't, I can only conclude that you accept my points as valid and have no response.
>>> 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 ? > You cannot do this with virtual functions and you are wrong to suggest it > works correctly.
I find it really amusing who you are telling to that he is wrong about C++.
If you think that virtual function pointers cannot work, care to give an example code which demonstrates your claim?
You know, before making a claim it's usually a good idea to actually test that the claim is valid.
> >> 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 ?
The pointer points to the member function.
> You cannot do this with virtual functions and you are wrong to suggest it > works correctly. > A virtual function calling mechanism requires an object.
It is required to work also with virtual member functions. To make this possible, you have to specify an object when dereferencing the pointer to a member function.
If I were to implement such pointers, they would consist of the following: - A flag indicating if dynamic dispatch (for virtual member functions) is needed or not, and - The address of the function, for non-virtual member functions, or - The offset in the vtable, for virtual functions.
<snip>
> >> And what exactly would 'this' point to?
> > The class object you used in the dereferencing expression.
> A class is not an object.
I will give you this nitpick.
To answer the question again: 'this' points to the object, of class type, that was used in the dereferencing expression.
> No object was ever declared in your code.
> Once again you appear confused about classes an objects.
To me, it appears more like careless writing.
<snip>
> If you intend using a function as a standalone function why would you > define > it as a member function of an object type. This seems like bad program > design.
Who is talking about using member functions as stand-alone functions?
Bart v Ingen Schenau .........................................................................
I thought that was the whole point of their argument... To express the use of a member function , without it being connected to an object.?
> In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote: >>> I find it a bit ironic that you protest so loudly abour common concepts >>> of C++ programming, yet you lack such knowledge of the language.
>> The fact that you have began your posting with a direct insult to me
> How exactly is it "a direct insult" for me to find your behavior > ironic?
What part of "you lack such knowlege of the language" do you not understand to be an insult?
Don't bother replying because I'll just tell ya to fuck off anyway.
>> leaves >> me no other opinion than you are actually nothing more than an other >> clueless idiot who has nothing more than an UNREASONABLE argument to put >> forward.
> What that makes me think is that you are playing the "you insulted me" > card in order to get yourself out of having to actually answer the > objections presented to your claims.
> Perhaps if instead of playing that card you would actually demonstrate > how what I wrote is wrong, we could have a conversation. If you won't, > I can only conclude that you accept my points as valid and have no > response.
>>>> 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 ? >> You cannot do this with virtual functions and you are wrong to suggest >> it >> works correctly.
> I find it really amusing who you are telling to that he is wrong > about C++.
> If you think that virtual function pointers cannot work, care to give > an example code which demonstrates your claim?
I am not 'claiming' they don't work without objects , I am *telling* you they don't.
The onus is on you to show us an example of using a virtual function without an object, since you think it works.
>>> >> 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.
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 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Paul wrote: > "Juha Nieminen" <nos...@thanks.invalid> wrote in message <snip> >> I find it a bit ironic that you protest so loudly abour common concepts >> of C++ programming, yet you lack such knowledge of the language.
> The fact that you have began your posting with a direct insult to me leaves > me no other opinion than you are actually nothing more than an other > clueless idiot who has nothing more than an UNREASONABLE argument to put > forward.
"No other opinion" would seem to suggest that our opinions, or more precisely your ability to form an opinion, are limited. I find that somewhat surprising because your performance to date suggests that you are indeed exceptionally skilled at forming very strong opinions. You have persistently denied any limits to your abilities or knowledge, yet here you appear to concede a minor point. Typo?
>>>> >> 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.
> 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."
Paul wrote: > "Juha Nieminen" <nos...@thanks.invalid> wrote in message > news:4d276e5a$0$12283$7b1e8fa0@news.nbl.fi... >> In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote: >>>> I find it a bit ironic that you protest so loudly abour common concepts >>>> of C++ programming, yet you lack such knowledge of the language.
>>> The fact that you have began your posting with a direct insult to me
>> How exactly is it "a direct insult" for me to find your behavior >> ironic?
> What part of "you lack such knowlege of the language" do you not understand > to be an insult?
> Don't bother replying because I'll just tell ya to fuck off anyway.
>> 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.
> 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 > 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
Did you hear that? Sounded like "I'm mmeelllllllttttting"
>>>>> >> 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.
>> 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>>> >> 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.
>>> 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 . ????
>>>>>>> >> 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.
>>>> 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/
In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote:
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message > news:4d276e5a$0$12283$7b1e8fa0@news.nbl.fi... >> In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote: >>>> I find it a bit ironic that you protest so loudly abour common concepts >>>> of C++ programming, yet you lack such knowledge of the language.
>>> The fact that you have began your posting with a direct insult to me
>> How exactly is it "a direct insult" for me to find your behavior >> ironic?
> What part of "you lack such knowlege of the language" do you not understand > to be an insult?
If someone told me that I lack knowledge on quantum mechanics, which is absolutely true, why would I feel insulted? I *do* lack a lot of knowledge about quantum mechanics. Someone stating so, especially after I openly have admitted so, would simply be telling the truth. Where exactly is the insult?
You clearly stated that you don't know about member function pointers. Hence, rather obviously, you lack knowledge about them. Hence what I said was a true statement.
> Don't bother replying because I'll just tell ya to fuck off anyway.
You are still trying to play the "you insulted me" card, probably so that you don't have to discuss the actual arguments presented.
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message > news:4d276fa7$0$12283$7b1e8fa0@news.nbl.fi... >> In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote: >>> "James Kanze" <james.ka...@gmail.com> wrote in message >>>> &ClassName::functionName
>>>>> 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 ? >>> You cannot do this with virtual functions and you are wrong to suggest >>> it >>> works correctly.
>> I find it really amusing who you are telling to that he is wrong >> about C++.
>> If you think that virtual function pointers cannot work, care to give >> an example code which demonstrates your claim?
> I am not 'claiming' they don't work without objects , I am *telling* you > they don't.
> The onus is on you to show us an example of using a virtual function without > an object, since you think it works.
Now you are changing your claim. You claimed in your earlier post that "virtual function pointers cannot work", without mentioning anything about objects. Now you are moving the goalposts and changing the claim to "virtual function pointers cannot be called without an object", which is a completely different statement.
If you actually *read* what I wrote earlier, I gave you the exact syntax of how you can create a member function pointer and how you call it with an object. Nobody claimed that you can *call* the function without an object. What I said was that you can refer to a member function (in other words, take its address and assign it to a pointer) without an object, which would indicate that the function is not, in fact, tied to any specific object, but a free function which is only tied to a specific *class*. The function in question takes implicitly an object as parameter, which is why you have to supply one when you call it (while the syntax for this is special, it's in principle no different from calling a regular function which takes an object as parameter in the regular way).
In other words, there's little difference between this:
class A { public: void foo(); };
and this:
class A {}; void foo(A*);
(The major difference is the scope in which 'foo' is declared. In the former case 'foo' is specifically tied to the scope of A.)
Paul wrote: > I am not 'claiming' they don't work without objects , I am *telling* you > they don't.
> The onus is on you to show us an example of using a virtual function > without an object, since you think it works.
You got it backwards. If you claim that they don't work then you are responsible to provide a concrete case where they don't work, so that those interested in helping you can analyse your example and, from there, provide an answer.
>> I am not 'claiming' they don't work without objects , I am *telling* you >> they don't.
>> The onus is on you to show us an example of using a virtual function >> without an object, since you think it works.
> You got it backwards. If you claim that they don't work then you are > responsible to provide a concrete case where they don't work, so that > those interested in helping you can analyse your example and, from there, > provide an answer.
> Rui Maciel
A virtual function is an OOP mechanism that is generally considered to object related. The fact that someone has *claimed* they can be used without the prescence of an objcet does no tmean I have to prove otherwise.
The only thing *backwards* here completely incorrect interpretation..
> "James Kanze" <james.ka...@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?
From the object you call the pointer on.
> >> 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.
Your guarantees aren't worth much, since you obviously aren't familiar with C++. It does work, and I've done it. Several types, with different compilers (Sun CC, g++ and VC++, at least---although you need special compiler options with VC++ if everything isn't in the same translation unit).
> >> A virtual function calling mechanism requires an object. > > Using a pointer to a member requires an object. So? > The point was to show that a member function can be called > *without * an object.
Whose point, where and when? You're just making things up as you go along, trying to bluff your way out, rather than just admitting that you really don't know C++.
On Jan 8, 5:09 am, Garrett Hartshaw <gharts...@gmail.com> wrote:
> On 01/07/2011 11:35 PM, Paul wrote:
[...]
> > 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).
Maybe. That's one implementation technique. In other implementations, the pointer actually points to some other function entirely, which then makes the virtual function call.
The important thing, I think, is that these functions (however many) live independently of any objects.
>>>>>>>> >> 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.
>>>>> 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.
No, you cannot use a virtual function without an object. A virtual function is basically a pointer that exists within an object, a virtual function never actually exists as a function hence *virtual* function. It is impossible to invoke a virtual function without the existence of an object. The object contains the pointer (that is the virtual function).
Hope this makes sense to you. Some peope are obviously confused between a precompile time entity(class) and an object. A function is not contained within a class anymore than it is contained within an object, with: wanda.blowBubbles(); This statement contains an object and a member function, there is no class here. This member function does not exist until it's invoked on an object. The function is exclusively tied to the object, (*not the class*), the class is stored on some file on an old dusty computer on the other side of the world. After the code is compiled a class no longer exists , a class is a precompile time entity in C++, a class in C++ is not the same as Java class.
I don't know what is wrong these people who cannot understand this , they are obviously very very ignorant and confused, please don't be one of them
>>>>>>>>> >> 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.
>>>>>> 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.
> No, you cannot use a virtual function without an object. > A virtual function is basically a pointer that exists within an object, > a virtual function never actually exists as a function hence *virtual* > function. > It is impossible to invoke a virtual function without the existence of > an object. The object contains the pointer (that is the virtual function).
You are wrong yet again; you obviously do not know C++. The address of a virtual function is contained within a vtable; it doesn't exist within an object; all that exists within an object is a pointer to the vtable if the object is of class type and the class contains at least one virtual function. Objects do not contain member functions (virtual or not); classes contain member functions (virtual or not).
> Hope this makes sense to you. > Some peope are obviously confused between a precompile time > entity(class) and an object. > A function is not contained within a class anymore than it is contained > within an object, with: > wanda.blowBubbles(); > This statement contains an object and a member function, there is no > class here. This member function does not exist until it's invoked on an
Wrong yet again; member functions exist within the code segment before any objects are created at runtime.
> object. The function is exclusively tied to the object, (*not the > class*), the class is stored on some file on an old dusty computer on > the other side of the world. > After the code is compiled a class no longer exists , a class is a > precompile time entity in C++, a class in C++ is not the same as Java > class.
> I don't know what is wrong these people who cannot understand this , > they are obviously very very ignorant and confused, please don't be one > of them
I suggest you read a C++ book or two and stop trolling your ignorance in this newsgroup wasting people's time.
>> No, you cannot use a virtual function without an object. >> A virtual function is basically a pointer that exists within an object, >> a virtual function never actually exists as a function hence *virtual* >> function. >> It is impossible to invoke a virtual function without the existence of >> an object. The object contains the pointer (that is the virtual >> function).
> You are wrong yet again; you obviously do not know C++. The address of a > virtual function is contained within a vtable; it doesn't exist within > an object; all that exists within an object is a pointer to the vtable > if the object is of class type and the class contains at least one > virtual function. Objects do not contain member functions (virtual or > not); classes contain member functions (virtual or not).
It is important to note however that the use of vtables is an implementaiton specific way of doing things (vtables are not mentioned by the standard AFAIK). I do not know of any implementations that do not use vtables however; this is down to the fact that the vtable solution to the problem of dynamic dispatch is efficient and not memory intensive (requiring only a single pointer in an object when using single inheritance).
