Altering the VTBL at runtime
Hey ho friends, I got a question again.
Is it possible to alter the Virtual Function Table of a c++
class at runtime to exchange some virtual functions with
my own funcs. The thing is, that I want to write a DLL for my
*Enemy classes* but it should only contain AI related functions.
Doing it the old fashioned way with Base classes I would have to insert the rest of the cpp code in the dll too.
Well, I hope that doesn''t sound too confusing after all.
I''m waiting for your replies, thx.
--::[Madhed]::-
What precisely are you trying to do?
I mean, ultimately, yes, it''s possible, but not in C++, and I don''t see why you would want to, either.
I mean, ultimately, yes, it''s possible, but not in C++, and I don''t see why you would want to, either.
It sounds like you want polymorphism. Do a search, or maybe someone else will be nice enough to show you how.
In short, your base class would contain pure-virtual functions for the "to be defined" functions:
This allows you later to have a list of Enemy* pointers (which are really pointing to derived classes). When you call the DoSomething() method on the Enemy* pointer, it actually calls the derived class function.
In short, your base class would contain pure-virtual functions for the "to be defined" functions:
class Enemy{public: // Force a derived class to define the DoSomething method. int DoSomething(int whatever)=0; int OtherFunction() { // code common to all }};
This allows you later to have a list of Enemy* pointers (which are really pointing to derived classes). When you call the DoSomething() method on the Enemy* pointer, it actually calls the derived class function.
Thank you both ,but no that''s not what I want.
I want to do something like that:
class Something
{
virtual void FuncA();
virtual void FuncB();
virtual void FuncC();
}
void MyFuncA()
{
}
void YourFuncB()
{
}
void HisFuncC()
{
}
Something InstSth;
InstSth.FuncA = &MyFuncA
InstSth.FuncB = &YourFuncB
InstSth.FuncC = &HisFuncC
It''s not actual code, ok
I hope that makes it clear. The whole point is, I want to
have Objects with certain member functions that can be accessed
by interfaces. I want other users to override these classes
but limit them to override just certain Functions by providing
new Functions and then, at runtime change the VTBL to point to
their newly created function. The problem is, one portion of the
class will be created by the .exe file and the other part (the
overrided functions) would be created by a user .dll. I haven''t
found any information on how to do this. I''m pretty certain that
this is not possible with standard c++ code anyway.
80% at least
By the way, how do you insert those cool ''code windows'' in
your reply?
--::[Madhed]::-
I want to do something like that:
class Something
{
virtual void FuncA();
virtual void FuncB();
virtual void FuncC();
}
void MyFuncA()
{
}
void YourFuncB()
{
}
void HisFuncC()
{
}
Something InstSth;
InstSth.FuncA = &MyFuncA
InstSth.FuncB = &YourFuncB
InstSth.FuncC = &HisFuncC
It''s not actual code, ok
I hope that makes it clear. The whole point is, I want to
have Objects with certain member functions that can be accessed
by interfaces. I want other users to override these classes
but limit them to override just certain Functions by providing
new Functions and then, at runtime change the VTBL to point to
their newly created function. The problem is, one portion of the
class will be created by the .exe file and the other part (the
overrided functions) would be created by a user .dll. I haven''t
found any information on how to do this. I''m pretty certain that
this is not possible with standard c++ code anyway.
80% at least
By the way, how do you insert those cool ''code windows'' in
your reply?
--::[Madhed]::-
Like DrPizza said, it can be done but it''s not advised. I don''t believe the C++ standard covers how the compiler implements virtual functions so how the table is set up (or even if one exists) could vary from compiler to compiler.
Why not create an AI class hierarchy. Create a base class and then derive from it classes that implement specific functionality. Have the *Enemy classes* contain a pointer to the base class (Has a relationship) and assign to it the appropriate derived class. Your *Enemy classes* then use the contained class for AI processing. And there’s no need to include the *Enemy classes* code in the DLL.
Why not create an AI class hierarchy. Create a base class and then derive from it classes that implement specific functionality. Have the *Enemy classes* contain a pointer to the base class (Has a relationship) and assign to it the appropriate derived class. Your *Enemy classes* then use the contained class for AI processing. And there’s no need to include the *Enemy classes* code in the DLL.
Why do you feel that inheritance is the way to solve this problem?
If you want writable function pointers, it sounds to me like you should be using function pointers, and not wanting to fuck around with the v-table.
If you want writable function pointers, it sounds to me like you should be using function pointers, and not wanting to fuck around with the v-table.
well actually I thought the vtable contains function
pointers and it would be pretty easy to change them.
After all It seems that it''s not..
Solo''s idea seams pretty straight-forward, I might want
to check that out. Solo, have you tried sth. like that before?
ehm... what about those ''code windows''? :D
Thx to you all.
--::[Madhed]::-
pointers and it would be pretty easy to change them.
After all It seems that it''s not..
Solo''s idea seams pretty straight-forward, I might want
to check that out. Solo, have you tried sth. like that before?
ehm... what about those ''code windows''? :D
Thx to you all.
--::[Madhed]::-
quote:
Solo, have you tried sth. like that before?
Sure. It''s basic OOP design. And easy to use if you load the DLL implicitly. The only catch is that it''s going to require a little more work if you want to load the DLL explicitly. You''ll need some sort of factory function (or function + class) to create and return the AI classes (like COM''s DllGetClassObject). This becomes necessary because Windows provides a means to get the address of functions (GetProcAddress) in the DLL but no means of getting at the classes in the DLL. And the names of class functions are decorated (mangled) so guessing them becomes difficult.
BTW, Check the FAQ for help with including quotes, source, ect.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement