Альтернативы C++ указателям void * (это не шаблоны)

Полиморфизм и шаблоны очень хорошо работают вместе, если вы их правильно используете.

В любом случае, я понимаю, что вы хотите хранить только один тип объектов в каждом экземпляре контейнера. Если да, используйте шаблоны. Это предотвратит ошибочное сохранение неправильного типа объекта.

Что касается интерфейсов контейнеров: в зависимости от вашего дизайна, возможно, вы тоже сможете сделать их шаблонными, и тогда у них будут такие методы, как void push(T* new_element). Подумайте, что вы будете знать об объекте, когда захотите добавить его в контейнер (неизвестного типа). Откуда в первую очередь возьмется объект? Функция, возвращающая void*? Вы знаете, что это будет сравнимо? По крайней мере, если все хранимые классы объектов определены в вашем коде, вы можете заставить их все унаследовать от общего предка, скажем, Storable, и использовать Storable* вместо void*.

Теперь, если вы видите, что объекты всегда будут добавляться в контейнер с помощью такого метода, как void push(Storable* new_element), тогда действительно не будет никакой дополнительной ценности в том, чтобы сделать контейнер шаблоном. Но тогда вы узнаете, что он должен хранить Storables.

Самое простое - определить абстрактный базовый класс Container и создать подкласс для каждого типа элементов, которые вы, возможно, захотите сохранить. Затем вы можете использовать любой стандартный класс коллекции (std::vector, std::list и т. д.) Для хранения указателей на Container. Имейте в виду, что, поскольку вы будете хранить указатели, вам придется обрабатывать их выделение / освобождение.

Однако тот факт, что вам нужна одна коллекция для хранения объектов столь сильно разных типов, указывает на то, что что-то может быть не так с дизайном вашего приложения. Возможно, лучше еще раз вернуться к бизнес-логике, прежде чем реализовывать этот универсальный контейнер.

Вы можете использовать стандартный контейнер boost :: any, если вы храните в нем действительно произвольные данные.

Похоже, вы бы предпочли иметь что-то вроде boost :: ptr_container, где все, что может хранится в контейнере, должно происходить от некоторого базового типа, а сам контейнер может давать вам ссылку только на базовый тип.

Используя полиморфизм, вы в основном остаетесь с базовым классом для контейнера и производными классами для типов данных. Базовый класс / производные классы могут иметь столько виртуальных функций, сколько вам нужно, в обоих направлениях.

Конечно, это будет означать, что вам также нужно будет обернуть примитивные типы данных в производные классы. Если бы вы пересмотрели использование шаблонов в целом, я бы использовал их именно здесь. Создайте один производный класс из базы, которая является шаблоном, и используйте его для примитивных типов данных (и других, где вам не нужно больше функциональности, чем предусмотрено шаблоном).

Не забывайте, что вы можете облегчить себе жизнь с помощью typedef для каждого из шаблонных типов, особенно если вам позже понадобится превратить один из них в класс.

Во-первых, шаблоны и полиморфизм - это ортогональные концепции, и они хорошо сочетаются друг с другом. Далее, зачем вам нужна конкретная структура данных? Что насчет STL или структур данных Boost (в частности, указатель, содержащий) вам не подходит.

Учитывая ваш вопрос, похоже, что вы неправильно используете наследование в своей ситуации. Можно создать «ограничения» для содержимого ваших контейнеров, особенно если вы используете шаблоны. Эти ограничения могут выходить за рамки того, что вам могут дать ваш компилятор и компоновщик. На самом деле с наследованием такого рода вещи более неудобны, и ошибки, скорее всего, оставлены на время выполнения.

Разве у вас нет корневого класса контейнера, который содержит элементы:

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();
       }
    }
};

Затем эти контейнеры можно передавать полиморфно:

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();

Это дает вам интерфейс контейнера типобезопасным универсальным способом.

Если вы хотите добавить ограничения к типу элементов, которые могут содержаться, вы можете сделать что-то вроде этого:

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
};

Вы также можете проверить Библиотека проверки концепции Boost (BCCL), который предназначен для обеспечения ограничений на параметры шаблонов шаблонных классов, в данном случае ваших контейнеров.

И просто повторю то, что говорили другие, у меня никогда не было проблем со смешиванием полиморфизма и шаблонов, и я проделал с ними довольно сложные вещи.

Вы не могли отказаться от Java-подобных интерфейсов и также использовать шаблоны. Предложение Джоша общего базового шаблона. Контейнер, безусловно, позволит вам полиморфно передавать Контейнеры и их дочерние элементы, но, кроме того, вы, безусловно, можете реализовать интерфейсы как абстрактные классы, которые будут содержащимися элементами. Нет причин, по которым вы не могли создать абстрактный класс IComparable, как вы предложили, чтобы у вас могла быть полиморфная функция следующим образом:

class Whatever
{
   void MyPolymorphicMethod(Container<IComparable*> &listOfComparables);
}

Теперь этот метод может принимать любой дочерний элемент Container, содержащий любой класс, реализующий IComparable, поэтому он будет чрезвычайно гибким.