Store Base and Child objects in array without dynamic allocation

[rozick1]

Hi

I have the following code:

#include <iostream>

using namespace std;

class Base
{
    protected:
        int num = 10;
    
    public:
        int virtual getNum()
        {
            return num;
        }
};

class Child : public Base
{
    public:
        int virtual getNum()
        {
            return num * 5;
        }
};

int main()
{
   
   Base *b[2];
   b[0] = new Base();
   b[1] = new Child();
   
   cout << b[0]->getNum() << endl; // 10
   cout << b[1]->getNum() << endl; // 50
   
   
   return 0;
}

Is there anyway of implementing similar functionality without dynamic functionality (i.e. storing Base or Child objects, or points to the same, in the same array)? I am working on an embedded system where I am supposed to only use static allocation of memory.

Thanks

[Ganado]

You can still use polymorphism with static allocation of memory. But you need to make sure that the pointer/reference you're using doesn't outlive the object itself. I realize your example is just that -- an example, but what I mean is something like:

// have the actual objects in memory already (perhaps existing for the full lifetime of the process)
Base base;
Child child;

// use references/pointers to these existing objects
Base *b[2] { &base, &child };

b[0]->getNum();
b[1]->getNum();

[rozick1]

thanks, my question wasn't clear.

What I want to do is to add Base or Child objects to the array depending upon user input (e.g. an array of 5 could hold 2 Base objects and 3 Child objects or 3 Base objects and 2 child objects).

I suppose this isn't possible as the compiler needs to know at compile time the size of the array?

[mbozzi]

storing Base or Child objects [...] in the same array

You certainly can't, because every object of class type is larger than its base class subobject if one exists, except in cases where both objects are subject to EBO.

If you guaranteed that all Child objects were at most a particular size there might be ground to stand on.

Consider following Ganado's suggestion.

[Ganado]

Polymorphism needs to happen through a reference or pointer. At the extremes of your example, you don't know if you are pointing to 5 Child objects, or 5 Base objects (or I assume some further derived type).

One funny thing you could do is that if you need an array of size N, then you need to allocate 2N objects total, to account for both extremes (user choosing all objects of type A, user choosing all objects of type B). But this probably isn't practical, so something better is needed.

Alternatively, you can think about the data more, and figure out where you can perhaps just have the data itself serve as polymorphism instead of dealing with pointers and such. But this ultimately depends on the specifics of the problem, and the data you have.

For example, in your example, the difference between the child and the base is that the child has a factor of 5 applied to it. So why not just make that part of the data of your class?

class Foo {
 public:
    int base_value;
    int factor;

    int getNum()
    {
        return base_value * factor;
    }
};

Then, adjust factor based on user input (could be 1 or 5). Again, I realize your actual use case might be more complicated than this, but it's a starting point that you could explore.

In other words, if you can't allocate more memory on the fly, then you need to make sure the memory you have at the start is the "greatest common denominator" of all the possibilities you wish to handle.

_________________________________________

Take what I say with a grain of salt; I am not an embedded programmer and I don't know the details of what people in that field have to deal with. I know other embedded programmers that still use polymorphism in their code, but they allocate everything they'll possibly need up front at the beginning of the program, and the resources used are relatively beefy for an embedded system.