I am on a micro controller (which means I can only have static memory allocation) and I am trying to work with inheritance.....

Suppose I have a abstract class Image and an abstract class Font. An instance of Font can return an Image based off of the char given in a function like so:

Font* mf;
Image* image = mf->GetImage("a");

Now the real issue is I have no idea what to do for the GetImage Function.

The problem is this: in c++ for you to have a member of an abstract class you have to use it as a pointer. So my dilemma is that I have a Font which wants to create a new Image and then return it.

If it returns a pointer to its newly created Image you are returning a reference to a temporary object:

Image* FontImpl::GetImage(char c){
  return &ImageImpl(c);  //This object is destroyed once this function exits

And then if I return I try to return an actual type like this:

Image FontImpl::GetImage(char c){
  return ImageImpl(c);   //Cannot cast from ImageImpl to Image

So is there an idiom or something for this kind of static memory problem?

EDIT: This is what I am doing as a temporary (possibly permanent) fix...let me know what you think:

I have a new class called UnionBase which is templated. The idea behind using this class is it can be any of the Derived types which you put into the template....You would use it like so:

UnionBase<Image,ImageImpl1,ImageImpl2> myImage;
myImage = ImageImpl1();  //I can assign to it any type in the templates
myImage->ImageMethod();  //I can use all of the methods of the base class

Using this idiom I would then do this:

void FontImpl::GetImage(char c, UnionBase& b){
 b = //Set it to somthing

The UnionBase type allocates the size of its largest member so all of them can fit... if you want me to post code for it I can.

  • Can there be more than one image in existence at a time for a given font? Commented May 12, 2016 at 2:14
  • @VaughnCato Yes unfortunately...but I know how many there are at the start of the program
    – DarthRubik
    Commented May 12, 2016 at 12:23
  • It sounds like you want to have a static object pool. Your FontImpl::GetImage would allocate an ImageImpl object from the pool and return a pointer to it. The ImageImpl destructor would return the object to the pool. Commented May 12, 2016 at 13:30
  • Does every concrete Font provide every possible character Image? Is every Image for 'a' identical for a given font?
    – Useless
    Commented May 12, 2016 at 16:48
  • @Useless Every font either returns a real Image for each char or returns an image with 0 width and height....No each font gives (or could give) a different image for an 'a'
    – DarthRubik
    Commented May 12, 2016 at 21:46

1 Answer 1


If you can't do dynamic allocation, you must statically allocate all possible ImageImpl instances that could be returned by FontImpl::GetImage and return a pointer to one of those based on the parameter that gets passed in.

For example:

static ImageImpl image_a;
static ImageImpl image_b;
static ImageImpl image_z;

Image* FontImpl::GetImage(char c){
    case 'a':
        return &image_a;
    case 'b':
        return &image_b;
    case 'z':
        return &image_z;
  • Thanks for the input on the bug in my code. Too bad my solution wouldn't work. Although your code does work, it seems like way too much effort and you having to know beforehand what the images are going to be. :( Perhaps completely giving up the polymorphism is the best approach in this specific case.
    – Andy
    Commented May 12, 2016 at 7:47
  • @DavidPacker I don't know if this is what I am looking for.....I posted my quick band aid solution that I came up with
    – DarthRubik
    Commented May 12, 2016 at 12:51
  • If you don't want a switch/case, you can just declare an array of {char; Image} structs for each concrete font in sorted order, and search it. The search part is mechanical and can probably go in the base class.
    – Useless
    Commented May 12, 2016 at 16:50
  • @DarthRubik: The trick with UnionBase works best if the set of derived classes is stable and relatively small. The problem is that adding a derived class will cause a massive rebuild, because all places that depend on the Image interface will be affected. Commented May 12, 2016 at 19:01
  • @BartvanIngenSchenau I do every thing all headers anyways on my micro projects so that is not a huge deal
    – DarthRubik
    Commented May 12, 2016 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.