Mixing
understand the pointer pointer in c++ to get the function call [closed]
I am little confused about the pointer statement in the following code.
The purpose of the pointer is to access the virtual function from virtual table.here is link of the article.
http://kaisar-haque.blogspot.com/2008/07/c-accessing-virtual-table.html
1 #include <iostream>
2
3 using namespace std;
4
5 //a simple class
6 class X
7 {
8 public:
9 //fn is a simple virtual function
10 virtual void fn()
11 {
12 cout << "n = " << n << endl;
13 }
14
15 //a member variable
16 int n;
17 };
18
19 int main()
20 {
21 //create an object (obj) of class X
22 X *obj = new X();
23 obj->n = 10;
24
25 //get the virtual table pointer of object obj
26 int* vptr = *(int**)obj;
27
28 // we shall call the function fn, but first the following assembly code
29 // is required to make obj as 'this' pointer as we shall call
30 // function fn() directly from the virtual table
31 __asm
32 {
33 mov ecx, obj
34 }
35
36 //function fn is the first entry of the virtual table, so it's vptr[0]
37 ( (void (*)()) vptr[0] )();
38
39 //the above is the same as the following
40 //obj->fn();
41
42 return 0;
43 }
44
so, i want to know the how to understand the line number 26.
c++ pointers
asked Jan 2 at 17:28
user3774426user3774426
82
closed as unclear what you're asking by πάντα ῥεῖ, Neil Butterworth, user4581301, genpfault, Billal Begueradj Jan 3 at 6:23
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 1 more comment
I am little confused about the pointer statement in the following code.
The purpose of the pointer is to access the virtual function from virtual table.here is link of the article.
http://kaisar-haque.blogspot.com/2008/07/c-accessing-virtual-table.html
1 #include <iostream>
2
3 using namespace std;
4
5 //a simple class
6 class X
7 {
8 public:
9 //fn is a simple virtual function
10 virtual void fn()
11 {
12 cout << "n = " << n << endl;
13 }
14
15 //a member variable
16 int n;
17 };
18
19 int main()
20 {
21 //create an object (obj) of class X
22 X *obj = new X();
23 obj->n = 10;
24
25 //get the virtual table pointer of object obj
26 int* vptr = *(int**)obj;
27
28 // we shall call the function fn, but first the following assembly code
29 // is required to make obj as 'this' pointer as we shall call
30 // function fn() directly from the virtual table
31 __asm
32 {
33 mov ecx, obj
34 }
35
36 //function fn is the first entry of the virtual table, so it's vptr[0]
37 ( (void (*)()) vptr[0] )();
38
39 //the above is the same as the following
40 //obj->fn();
41
42 return 0;
43 }
44
so, i want to know the how to understand the line number 26.
c++ pointers
asked Jan 2 at 17:28
user3774426user3774426
82
closed as unclear what you're asking by πάντα ῥεῖ, Neil Butterworth, user4581301, genpfault, Billal Begueradj Jan 3 at 6:23
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
7
Don't do hackery like this. It's way outside of what is well-defined in C++, and not necessary.
– Lightness Races in Orbit
Jan 2 at 17:30
This code is undefined behavior. It may work mostly by chance with a specific version of a specific compiler on a specific operating system, but there's never a reason to do this.
– Mooing Duck
Jan 2 at 17:30
3
*(int**)obj;invokes undefined behavior
– UnholySheep
Jan 2 at 17:30
1
That being said, what about the long explanation in the linked article is not clear? We don't want to repeat the whole explanation only to then find out what part you didn't get.
– Lightness Races in Orbit
Jan 2 at 17:31
1
That article is talking about implementation details as if they were facts of c++. This isn't how c++ works. Even if you are on an implementation where what it assumes is true, it uses undefined behavior and might stop working at any time. It doesn't even specify how it was built or with what compiler versions, so you can't even semi-reliably use what it describes. There's hardly anything useful to learn from it. Line 26 is undefined behavior and there is nothing to understand from it other than to not do that.
– François Andrieux
Jan 2 at 18:26
|
show 1 more comment
I am little confused about the pointer statement in the following code.
The purpose of the pointer is to access the virtual function from virtual table.here is link of the article.
http://kaisar-haque.blogspot.com/2008/07/c-accessing-virtual-table.html
1 #include <iostream>
2
3 using namespace std;
4
5 //a simple class
6 class X
7 {
8 public:
9 //fn is a simple virtual function
10 virtual void fn()
11 {
12 cout << "n = " << n << endl;
13 }
14
15 //a member variable
16 int n;
17 };
18
19 int main()
20 {
21 //create an object (obj) of class X
22 X *obj = new X();
23 obj->n = 10;
24
25 //get the virtual table pointer of object obj
26 int* vptr = *(int**)obj;
27
28 // we shall call the function fn, but first the following assembly code
29 // is required to make obj as 'this' pointer as we shall call
30 // function fn() directly from the virtual table
31 __asm
32 {
33 mov ecx, obj
34 }
35
36 //function fn is the first entry of the virtual table, so it's vptr[0]
37 ( (void (*)()) vptr[0] )();
38
39 //the above is the same as the following
40 //obj->fn();
41
42 return 0;
43 }
44
so, i want to know the how to understand the line number 26.
c++ pointers
asked Jan 2 at 17:28
user3774426user3774426
82
I am little confused about the pointer statement in the following code.
The purpose of the pointer is to access the virtual function from virtual table.here is link of the article.
http://kaisar-haque.blogspot.com/2008/07/c-accessing-virtual-table.html
1 #include <iostream>
2
3 using namespace std;
4
5 //a simple class
6 class X
7 {
8 public:
9 //fn is a simple virtual function
10 virtual void fn()
11 {
12 cout << "n = " << n << endl;
13 }
14
15 //a member variable
16 int n;
17 };
18
19 int main()
20 {
21 //create an object (obj) of class X
22 X *obj = new X();
23 obj->n = 10;
24
25 //get the virtual table pointer of object obj
26 int* vptr = *(int**)obj;
27
28 // we shall call the function fn, but first the following assembly code
29 // is required to make obj as 'this' pointer as we shall call
30 // function fn() directly from the virtual table
31 __asm
32 {
33 mov ecx, obj
34 }
35
36 //function fn is the first entry of the virtual table, so it's vptr[0]
37 ( (void (*)()) vptr[0] )();
38
39 //the above is the same as the following
40 //obj->fn();
41
42 return 0;
43 }
44
so, i want to know the how to understand the line number 26.
c++ pointers
c++ pointers
asked Jan 2 at 17:28
user3774426user3774426
82
asked Jan 2 at 17:28
user3774426user3774426
82
asked Jan 2 at 17:28
user3774426user3774426
82
asked Jan 2 at 17:28
user3774426user3774426
82
asked Jan 2 at 17:28
user3774426user3774426
82
82
closed as unclear what you're asking by πάντα ῥεῖ, Neil Butterworth, user4581301, genpfault, Billal Begueradj Jan 3 at 6:23
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by πάντα ῥεῖ, Neil Butterworth, user4581301, genpfault, Billal Begueradj Jan 3 at 6:23
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
7
Don't do hackery like this. It's way outside of what is well-defined in C++, and not necessary.
– Lightness Races in Orbit
Jan 2 at 17:30
This code is undefined behavior. It may work mostly by chance with a specific version of a specific compiler on a specific operating system, but there's never a reason to do this.
– Mooing Duck
Jan 2 at 17:30
3
*(int**)obj;invokes undefined behavior
– UnholySheep
Jan 2 at 17:30
1
That being said, what about the long explanation in the linked article is not clear? We don't want to repeat the whole explanation only to then find out what part you didn't get.
– Lightness Races in Orbit
Jan 2 at 17:31
1
That article is talking about implementation details as if they were facts of c++. This isn't how c++ works. Even if you are on an implementation where what it assumes is true, it uses undefined behavior and might stop working at any time. It doesn't even specify how it was built or with what compiler versions, so you can't even semi-reliably use what it describes. There's hardly anything useful to learn from it. Line 26 is undefined behavior and there is nothing to understand from it other than to not do that.
– François Andrieux
Jan 2 at 18:26
|
show 1 more comment
7
Don't do hackery like this. It's way outside of what is well-defined in C++, and not necessary.
– Lightness Races in Orbit
Jan 2 at 17:30
This code is undefined behavior. It may work mostly by chance with a specific version of a specific compiler on a specific operating system, but there's never a reason to do this.
– Mooing Duck
Jan 2 at 17:30
3
*(int**)obj;invokes undefined behavior
– UnholySheep
Jan 2 at 17:30
1
That being said, what about the long explanation in the linked article is not clear? We don't want to repeat the whole explanation only to then find out what part you didn't get.
– Lightness Races in Orbit
Jan 2 at 17:31
1
That article is talking about implementation details as if they were facts of c++. This isn't how c++ works. Even if you are on an implementation where what it assumes is true, it uses undefined behavior and might stop working at any time. It doesn't even specify how it was built or with what compiler versions, so you can't even semi-reliably use what it describes. There's hardly anything useful to learn from it. Line 26 is undefined behavior and there is nothing to understand from it other than to not do that.
– François Andrieux
Jan 2 at 18:26
7
7
Don't do hackery like this. It's way outside of what is well-defined in C++, and not necessary.
– Lightness Races in Orbit
Jan 2 at 17:30
Don't do hackery like this. It's way outside of what is well-defined in C++, and not necessary.
– Lightness Races in Orbit
Jan 2 at 17:30
This code is undefined behavior. It may work mostly by chance with a specific version of a specific compiler on a specific operating system, but there's never a reason to do this.
– Mooing Duck
Jan 2 at 17:30
This code is undefined behavior. It may work mostly by chance with a specific version of a specific compiler on a specific operating system, but there's never a reason to do this.
– Mooing Duck
Jan 2 at 17:30
3
3
*(int**)obj; invokes undefined behavior– UnholySheep
Jan 2 at 17:30
*(int**)obj; invokes undefined behavior– UnholySheep
Jan 2 at 17:30
1
1
That being said, what about the long explanation in the linked article is not clear? We don't want to repeat the whole explanation only to then find out what part you didn't get.
– Lightness Races in Orbit
Jan 2 at 17:31
That being said, what about the long explanation in the linked article is not clear? We don't want to repeat the whole explanation only to then find out what part you didn't get.
– Lightness Races in Orbit
Jan 2 at 17:31
1
1
That article is talking about implementation details as if they were facts of c++. This isn't how c++ works. Even if you are on an implementation where what it assumes is true, it uses undefined behavior and might stop working at any time. It doesn't even specify how it was built or with what compiler versions, so you can't even semi-reliably use what it describes. There's hardly anything useful to learn from it. Line 26 is undefined behavior and there is nothing to understand from it other than to not do that.
– François Andrieux
Jan 2 at 18:26
That article is talking about implementation details as if they were facts of c++. This isn't how c++ works. Even if you are on an implementation where what it assumes is true, it uses undefined behavior and might stop working at any time. It doesn't even specify how it was built or with what compiler versions, so you can't even semi-reliably use what it describes. There's hardly anything useful to learn from it. Line 26 is undefined behavior and there is nothing to understand from it other than to not do that.
– François Andrieux
Jan 2 at 18:26
|
show 1 more comment
1 Answer
1
active
oldest
votes
The code is trying to do a hack base on some possible implementation of a virtual functionality in c++. The implementation of the vtable is not defined in the standard and its could be different with different compilers. It could be a subject to optimization as well.
The article is 10 years old and assumes a particular vtable implementation which was kind of common before those days:
first hidden pointer in the object (at object starting address) points to a array of functions.
the array of functions represents all virtual functions in the class.
Only compiler knows in which order they are put in the array. Declaration order was used usually.
Assuming the above implementation, address of 'obj' is really an address of the pointer to the virtual table. The example uses assumes that the function pointers can be represented as ints. It is simply not true for 64-bit OS and many others. And int *vptr is a pointer to this array. So, obj points to a pointer to an array of int's (int**). Consequently, *(int**)obj is the pointer to the array itself.
The example then does another unsafe conversion from the vptr[0] (which is 'int') to a pointer to the function.
So, as a result you have a series of undefined or unsafe behaviors which could work for a particular implementation of a particular version of a particular compiler (probably 10 years old, same as the article).
DO NOT USE IT!!!
answered Jan 2 at 18:50
SergeSerge
4,11221016
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The code is trying to do a hack base on some possible implementation of a virtual functionality in c++. The implementation of the vtable is not defined in the standard and its could be different with different compilers. It could be a subject to optimization as well.
The article is 10 years old and assumes a particular vtable implementation which was kind of common before those days:
first hidden pointer in the object (at object starting address) points to a array of functions.
the array of functions represents all virtual functions in the class.
Only compiler knows in which order they are put in the array. Declaration order was used usually.
Assuming the above implementation, address of 'obj' is really an address of the pointer to the virtual table. The example uses assumes that the function pointers can be represented as ints. It is simply not true for 64-bit OS and many others. And int *vptr is a pointer to this array. So, obj points to a pointer to an array of int's (int**). Consequently, *(int**)obj is the pointer to the array itself.
The example then does another unsafe conversion from the vptr[0] (which is 'int') to a pointer to the function.
So, as a result you have a series of undefined or unsafe behaviors which could work for a particular implementation of a particular version of a particular compiler (probably 10 years old, same as the article).
DO NOT USE IT!!!
answered Jan 2 at 18:50
SergeSerge
4,11221016
add a comment |
The code is trying to do a hack base on some possible implementation of a virtual functionality in c++. The implementation of the vtable is not defined in the standard and its could be different with different compilers. It could be a subject to optimization as well.
The article is 10 years old and assumes a particular vtable implementation which was kind of common before those days:
first hidden pointer in the object (at object starting address) points to a array of functions.
the array of functions represents all virtual functions in the class.
Only compiler knows in which order they are put in the array. Declaration order was used usually.
Assuming the above implementation, address of 'obj' is really an address of the pointer to the virtual table. The example uses assumes that the function pointers can be represented as ints. It is simply not true for 64-bit OS and many others. And int *vptr is a pointer to this array. So, obj points to a pointer to an array of int's (int**). Consequently, *(int**)obj is the pointer to the array itself.
The example then does another unsafe conversion from the vptr[0] (which is 'int') to a pointer to the function.
So, as a result you have a series of undefined or unsafe behaviors which could work for a particular implementation of a particular version of a particular compiler (probably 10 years old, same as the article).
DO NOT USE IT!!!
answered Jan 2 at 18:50
SergeSerge
4,11221016
add a comment |
The code is trying to do a hack base on some possible implementation of a virtual functionality in c++. The implementation of the vtable is not defined in the standard and its could be different with different compilers. It could be a subject to optimization as well.
The article is 10 years old and assumes a particular vtable implementation which was kind of common before those days:
first hidden pointer in the object (at object starting address) points to a array of functions.
the array of functions represents all virtual functions in the class.
Only compiler knows in which order they are put in the array. Declaration order was used usually.
Assuming the above implementation, address of 'obj' is really an address of the pointer to the virtual table. The example uses assumes that the function pointers can be represented as ints. It is simply not true for 64-bit OS and many others. And int *vptr is a pointer to this array. So, obj points to a pointer to an array of int's (int**). Consequently, *(int**)obj is the pointer to the array itself.
The example then does another unsafe conversion from the vptr[0] (which is 'int') to a pointer to the function.
So, as a result you have a series of undefined or unsafe behaviors which could work for a particular implementation of a particular version of a particular compiler (probably 10 years old, same as the article).
DO NOT USE IT!!!
answered Jan 2 at 18:50
SergeSerge
4,11221016
The code is trying to do a hack base on some possible implementation of a virtual functionality in c++. The implementation of the vtable is not defined in the standard and its could be different with different compilers. It could be a subject to optimization as well.
The article is 10 years old and assumes a particular vtable implementation which was kind of common before those days:
first hidden pointer in the object (at object starting address) points to a array of functions.
the array of functions represents all virtual functions in the class.
Only compiler knows in which order they are put in the array. Declaration order was used usually.
Assuming the above implementation, address of 'obj' is really an address of the pointer to the virtual table. The example uses assumes that the function pointers can be represented as ints. It is simply not true for 64-bit OS and many others. And int *vptr is a pointer to this array. So, obj points to a pointer to an array of int's (int**). Consequently, *(int**)obj is the pointer to the array itself.
The example then does another unsafe conversion from the vptr[0] (which is 'int') to a pointer to the function.
So, as a result you have a series of undefined or unsafe behaviors which could work for a particular implementation of a particular version of a particular compiler (probably 10 years old, same as the article).
DO NOT USE IT!!!
answered Jan 2 at 18:50
SergeSerge
4,11221016
answered Jan 2 at 18:50
SergeSerge
4,11221016
answered Jan 2 at 18:50
SergeSerge
4,11221016
answered Jan 2 at 18:50
SergeSerge
4,11221016
4,11221016
add a comment |
add a comment |
7
Don't do hackery like this. It's way outside of what is well-defined in C++, and not necessary.
– Lightness Races in Orbit
Jan 2 at 17:30
This code is undefined behavior. It may work mostly by chance with a specific version of a specific compiler on a specific operating system, but there's never a reason to do this.
– Mooing Duck
Jan 2 at 17:30
3
*(int**)obj;invokes undefined behavior– UnholySheep
Jan 2 at 17:30
1
That being said, what about the long explanation in the linked article is not clear? We don't want to repeat the whole explanation only to then find out what part you didn't get.
– Lightness Races in Orbit
Jan 2 at 17:31
1
That article is talking about implementation details as if they were facts of c++. This isn't how c++ works. Even if you are on an implementation where what it assumes is true, it uses undefined behavior and might stop working at any time. It doesn't even specify how it was built or with what compiler versions, so you can't even semi-reliably use what it describes. There's hardly anything useful to learn from it. Line 26 is undefined behavior and there is nothing to understand from it other than to not do that.
– François Andrieux
Jan 2 at 18:26