0

I have the following (examplery) classes

class ComponentA : public ComponentBase {
  Renderer renderer;
}

class Renderer {
  Renderer(std::vector<float> verts) : vertices(verts){};
  std::vector<float> vertices;
}

I'd like to keep my derived component classes flexible, so there could be many different renderers and of course other objects that are part of the component.

The renderer class does not have a default constructor, so I'd have to initialise it in the component's initialiser list or directly in the component's header file. Alternatively I could add a default constructor to renderer, but what if I have a class where a default constructor doesn't make sense or I don't want to implement one since it would require extra handling (ie setting a flag that the object isn't properly initialised)?

Additionally, the renderer could potentially not be necessary for the whole lifetime of the component, which would again require renderer to have some sort of "off" switch.

Now of course a (unique) pointer would solve the problem, but I'd like to avoid that if not necessary.

Are there any idioms/solutions to this problem I could use to handle these cases?

cboe
  • 429
  • 1
  • 9
  • 22
  • 3
    If you can have many Renderer, there should be inheritance so keeping a pointer or a reference to it in component is the way to go. – Eric Fortin Mar 21 '14 at 21:40
  • The point wasn't that the objects could have inheritance, but I guess there's no way around pointers... I guess it's still the way to go, I was just looking for a more comfortable solution – cboe Mar 21 '14 at 22:42
  • 1
    If renderer is not necessary for the components whole lifetime why not create a method void setRenderer(const std::shared_ptr &r) that would be used to enable/disable renderer for the component. disabling would be done by passing an empty shared_ptr. That way you are also free to construct renderer any way you like since you do it outside of the component. – virtus Mar 21 '14 at 22:59

1 Answers1

1

Is what you are looking for not just classical inherritance? I.e. something Like

class ComponentA : public ComponentBase {
  RendererBase& renderer;
  ComponentA(RederBase& r):renderer(r) {} 
}

class RenderBase {
  // Maybe some mandetory virtual functions in here
};

class RendererTypeFloat : public RenderBase {
  RendererTypeFloat(std::vector<float> verts) : vertices(verts){};
  std::vector<float> vertices;
}

class RendererTypeInt : public RenderBase {
  RendererTypeInt(std::vector<int> verts) : vertices(verts){};
  std::vector<int> vertices;
}
Soren
  • 13,623
  • 4
  • 34
  • 66
  • I guess that's the answer I was looking for, I was hoping there was some idiom that allows me to avoid references/pointers while getting the same advantages... I guess I didn't formulate my question properly. Thanks for the input! – cboe Mar 22 '14 at 01:48
  • There may be -- many times the abstractness of a class is alternatively done with the 'pimpl' http://stackoverflow.com/questions/60570/why-should-the-pimpl-idiom-be-used idiom also knows as 'Opaque pointer' http://en.wikipedia.org/wiki/Opaque_pointer – Soren Mar 24 '14 at 17:13