Help with this (pointers and polymorphism) - c++

Question

Here is my issue.
I'm creating my own GUI Api. All the Widgets are in a container which has add and remove functions. The widgets derive from a base widget class. Here is where I'm unsure. I would ideally like a flow like this:
user creates a (desired widget deriving from base class) pointer, the container allocates and manages resources, the user has a pointer to the widget and can make calls to it.
However, polymorphism makes this confusing. How could I get my container to create the right type of new? The issue here is that anyone can create a new widget (like SuperTextBoxWidget) which is why supplying a string and doing a switch would not solve this.
My other quick-fix alternative is to make the user responsible for doing the new, and providing the pointer to the container's add function. But this does not feel idiot proof to me, and it seems odd to have the user do the initial allocation, but then the container manages the rest including erasure.
What would be the best and cleanest way to go about this?
Thanks
just an idea of what I have so far:
class AguiWidgetContainer
{
std::vector<AguiWidgetBase*> widgets;
public:
AguiWidgetContainer(void);
~AguiWidgetContainer(void);
void handleEvent(ALLEGRO_EVENT* event);
int add(AguiWidgetBase *widget);
bool remove(int widgetId);
};

Answer 1

I can think of at least two ways to do this.
1. Provide a template version of add:
template<class T>
int add() {
widgets.push_back(new T);
}
2. Use a factory class:
You can have a base factory class that defines methods to allocate (and possibly also free) widgets. Your users then provide their own subclass of the factory that creates the correct type of widget. For example:
class AguiWidgetFactory {
AguiWidgetBase *createWidget() = 0;
};
class AguiSuperWidgetFactory : public AguiWidgetFactory {
AguiWidgetBase *createWidget() {
return new SuperTextBoxWidget();
}
};
Your add method then takes a factory object as input and uses it to create a new widget.

Answer 2

I would suggest borrowing from COM and making your base widget class a pure virtual interface which includes a function to destroy itself. Then implementers of your widget don't even all have to use the same allocator (important if you ever cross DLL boundaries).
EDIT: Example:
class IWidget
{
public:
virtual Size Measure() = 0;
virtual void Draw(Point) = 0;
//and so on
virtual void Release() = 0;
};
class TextBoxWidget : public IWidget
{
TextBoxWidget() {}
~TextBoxWidget() {}
public:
// implement IWidget functions, etc, etc
static TextBoxWidget* Create() { return new TextBoxWidget(); }
virtual void Release() { delete this; }
};
Now TextBoxWidget can only be created with TextBoxWidget::Create() and released with someTBW->Release(), and always uses new and delete inside the same DLL, guaranteeing that they match.

Answer 3

My other quick-fix alternative is to
make the user responsible for doing
the new, and providing the pointer to
the container's add function. But this
does not feel idiot proof to me, and
it seems odd to have the user do the
initial allocation, but then the
container manages the rest including
erasure.
Why does it feel odd to you?
If a container starts taking responsibility of allocating the objects to be contained, it violats SRP. I would recommend that you design your interfaces to accept pointers to Widget objects that are allocated by users. The container is only responsible for containing/storing/retreiving them.
The user also takes responsibility of deleting the allocated objects.
Most of STL containers work in this way.