1

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? – Vaughn Cato May 12 '16 at 2:14
  • @VaughnCato Yes unfortunately...but I know how many there are at the start of the program – DarthRubik May 12 '16 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. – Vaughn Cato May 12 '16 at 13:30
  • Does every concrete Font provide every possible character Image? Is every Image for 'a' identical for a given font? – Useless May 12 '16 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 May 12 '16 at 21:46
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){
    switch(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 May 12 '16 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 May 12 '16 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 May 12 '16 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. – Bart van Ingen Schenau May 12 '16 at 19:01
  • @BartvanIngenSchenau I do every thing all headers anyways on my micro projects so that is not a huge deal – DarthRubik May 12 '16 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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