Static function overload?

Question

To begin with, I understand that only non-static member functions can be virtual, but this is what I want:

• Base class defining an interface: so I can use base class pointers to access functions.

• For memory management purposes (this is an embedded system with limited overhead), I want the override functions to be statically distributed. I agree that with a static function there will be restrictions on how I can manipulate data in this function.

  My real thinking is that I can save the overload function by making it a wrapper for a function that is actually static.

Please do not tell me that I need to change my mind. That is why I ask the question. If you want to tell me that I am better off using c and using callbacks, please direct me to some reading material to explain the pitfalls of using an object-oriented approach. Is there an object-oriented design template that meets the requirements that I have listed?

Answer 1

Is there an object-oriented design template that meets the requirements that I have listed?

Yes, simple old virtual functions. Your desire is "the basic functions that need to be statically distributed." Virtual functions are statically distributed. That is, the code that implements the functions exists once and only once and is fixed at compile / link time. Depending on your linker command, they will most likely be stored in flash memory like any other function.

class I { public: virtual void doit() = 0; virtual void undoit() = 0; }; class A : public I { public: virtual void doit () { // The code for this function is created statically and stored in the code segment std::cout << "hello, "; } virtual void undoit () { // ditto for this one std::cout << "HELLO, "; } }; class B : public I { public: int i; virtual void doit() { // ditto for this one std::cout << "world\n"; } virtual void undoit() { // yes, you got it. std::cout << "WORLD\n"; } }; int main () { B b; // So, what is stored inside b? // There are sizeof(int) bytes for "i", // There are probably sizeof(void*) bytes for the vtable pointer. // Note that the vtable pointer doesn't change size, regardless of how // many virtual methods there are. // sizeof(b) is probably 8 bytes or so. } 

Answer 2

Static member functions are simply simple functions (like non-member functions) that are inside the class namespace. This means that you can consider them as simple functions, and the following solution should do:

 class Interface { public: void (*function) (); }; class Implementation: public Interface { public: Implementation() { function = impl_function; } private: static void impl_function() { // do something } }; 

then

 Implementation a; Interface* b = &a; b->function(); // will do something... 

The problem with this approach is that you will do almost what the compiler does for you, when you use virtual member functions, it’s just better (less code is needed, less error prone, and the pointer to the implementation functions is split). The main difference is that when using virtual your function would receive the (invisible) this parameter when called, and you could access member variables.

Thus, I would recommend that you simply not do this and use the usual virtual methods.

Answer 3

For memory management purposes (this is an embedded system with a limited drum) I want the override functions to be statically allocated.

All functions in C ++ are always statically allocated. The only exception is if you manually download and use JIT.

Answer 4

The overhead with virtual functions is twofold: in addition to the code for real implementations (which is in the code segment, like any other function that you write), there is a table of virtual functions, and there are pointers to this table. The virtual function table is present once for each derived class, and its size depends on the number of virtual functions. Each object must have a pointer to its table of virtual functions.

My point is that the overhead for all virtual function objects is the same regardless of how many virtual functions you have or how much code they contain. Thus, the way you organize your virtual functions should have a small effect on memory consumption, once you decide that you want some degree of polymorphism.