Дизайн шаблона контейнера-указателя

Question

Я хотел бы написать «универсальный» класс, представляющий общие указатели хранения контейнера. Должен ли я использовать публичное наследование или сдерживание?

template <class T> 
class List : public std::vector <T *> 
{ 
//... 
} 

Или

template <class T> 
class List 
{ 
private: 
    std::vector <T *> items; 
//... 
} 

Может некоторые проблемы возникают с абстрактными классами (т.е. виртуальный деструктор)?

Если ни одно из предложений не подходит, какой дизайн следует использовать (и вы могли бы включить короткий пример)?

Answer 1

Как насчет:

typedef std::vector<boost::shared_ptr<T> > List; 

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

Answer 2

Это уже сделано для Вас с Boost's pointer containers.

Мне не нравится boost, поэтому я бы хотел использовать только C++ 0x00 standard :-).
  — Ian (comment)

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

На самом деле, просто скопируйте код прямо из Boost. Это библиотека только для заголовков и должна быть прямой (т. Е. Несколько обходных решений для конкретной реализации). Boost's license очень либеральна, даже не требует упоминания Boost при распространении скомпилированных программ.

Answer 3

private Наследование - общая тактика для создания классов, которые реализуются в терминах другого. Код, который использует класс, не может сказать, что производный класс получен из частной базы, поэтому вы не окажетесь в ситуациях, которые обычно требуют виртуального деструктора.

Используйте команду using для импорта элементов из частной базы в производный класс. Например:

template<class T> 
class List: 
private std::vector<T> 
{ 
public: 
    using std::vector<T>::operator[]; 
    using std::vector<T>::size; 
}; 

Это немного грубо, но это дает вам некоторую гибкость. Вы можете начать с использования частного наследования, и это экономит вас при наборе текста по сравнению с написанием функций пересылки, но вы по-прежнему можете писать альтернативные варианты реализации по требованию. И тогда, если/когда это станет неуместным, вы можете изменить стиль реализации - возможно, например, в качестве члена есть vector, например, или, может быть, сделать все вручную без необходимости знать, что код клиента не потребуется изменять ,

Это идеальное решение для ситуаций, когда вы уверены, что в конечном итоге вам понадобится нестандартный тип контейнера, но у вас есть существующий тип контейнера, который в настоящее время больше подходит для счета. И это лучшее среднесрочное решение, чем typedef, потому что нет никакого риска для кода клиента случайно (или по назначению ...), используя два типа взаимозаменяемо.