Question

It looks like I had a fundamental misunderstanding about C++ :<

I like the polymorphic container solution. Thank you SO, for bringing that to my attention 🙂

---

So, we have a need to create a relatively generic container type object. It also happens to encapsulate some business related logic. However, we need to store essentially arbitrary data in this container – everything from primitive data types to complex classes.

Thus, one would immediately jump to the idea of a template class and be done with it. However, I have noticed C++ polymorphism and templates do not play well together. Being that there is some complex logic that we are going to have to work, I would rather just stick with either templates OR polymorphism, and not try to fight C++ by making it do both.

Finally, given that I want to do one or the other, I would prefer polymorphism. I find it much easier to represent constraints like ‘this container contains Comparable types’ – a la java.

Bringing me to the topic of question: At the most abstract, I imagine that I could have a ‘Container’ pure virtual interface that has something akin to ‘push(void* data) and pop(void* data)’ (for the record, I am not actually trying to implement a stack).

However, I don’t really like void* at the top level, not to mention the signature is going to change every time I want to add a constraint to the type of data a concrete container can work with.

Summarizing: We have relatively complex containers that have various ways to retrieve elements. We want to be able to vary the constraints on the elements that can go into the containers. Elements should work with multiple kinds of containers (so long as they meet the constraints of that particular container).

Edit: I should also mention that the containers themselves need to be polymorphic. That is my primary reason for not wanting to use templated C++.

So – should I drop my love for Java type interfaces and go with templates? Should I use void* and statically cast everything? Or should I go with an empty class definition ‘Element’ that declares nothing and use that as my top level class in the ‘Element’ hierarchy?

One of the reasons why I love stack overflow is that many of the responses provide some interesting insight on other approaches that I hadn’t not have even considered. So thank you in advance for your insights and comments.

Answer 1

Can you not have a root Container class that contains elements:

template <typename T> class Container { public:      // You'll likely want to use shared_ptr<T> instead.    virtual void push(T *element) = 0;    virtual T *pop() = 0;    virtual void InvokeSomeMethodOnAllItems() = 0; };  template <typename T> class List : public Container<T> {     iterator begin();     iterator end(); public:     virtual void push(T *element) {...}     virtual T* pop() { ... }     virtual void InvokeSomeMethodOnAllItems()      {        for(iterator currItem = begin(); currItem != end(); ++currItem)        {            T* item = *currItem;            item->SomeMethod();        }     } }; 

These containers can then be passed around polymorphically:

class Item { public:    virtual void SomeMethod() = 0; };  class ConcreteItem { public:     virtual void SomeMethod()      {         // Do something     } };    void AddItemToContainer(Container<Item> &container, Item *item) {    container.push(item); }  ...  List<Item> listInstance; AddItemToContainer(listInstance, new ConcreteItem()); listInstance.InvokeSomeMethodOnAllItems(); 

This gives you the Container interface in a type-safe generic way.

If you want to add constraints to the type of elements that can be contained, you can do something like this:

class Item { public:   virtual void SomeMethod() = 0;   typedef int CanBeContainedInList; };  template <typename T> class List : public Container<T> {    typedef typename T::CanBeContainedInList ListGuard;    // ... as before };