Можно ли наследовать реализацию от контейнеров STL, а не делегировать?
У меня есть класс, который адаптирует std :: vector для моделирования контейнера предметно-ориентированных объектов. Я хочу предоставить пользователю большую часть API-интерфейса std :: vector, чтобы он / она мог использовать знакомые методы (size, clear, at и т. Д.) И стандартные алгоритмы для контейнера. Это, кажется, повторяющийся шаблон для меня в моих проектах:
class MyContainer : public std::vector<MyObject>
{
public:
// Redeclare all container traits: value_type, iterator, etc...
// Domain-specific constructors
// (more useful to the user than std::vector ones...)
// Add a few domain-specific helper methods...
// Perhaps modify or hide a few methods (domain-related)
};
Я знаю практику предпочтения композиции наследованию при повторном использовании класса для реализации - но должен быть предел! Если бы я должен был делегировать все в std :: vector, было бы (по моим подсчетам) 32 функции пересылки!
Итак, мои вопросы ... Неужели так плохо наследовать реализацию в таких случаях? Каковы риски? Есть ли более безопасный способ, которым я могу реализовать это без так много печатать? Я еретик для использования наследования реализации? :)
Редактировать:
Как насчет того, чтобы дать понять, что пользователь не должен использовать MyContainer через указатель std :: vector <>:
// non_api_header_file.h
namespace detail
{
typedef std::vector<MyObject> MyObjectBase;
}
// api_header_file.h
class MyContainer : public detail::MyObjectBase
{
// ...
};
Библиотеки Boost, кажется, делают это все время.
Изменить 2:
Одним из предложений было использование бесплатных функций. Я покажу это здесь как псевдокод:
typedef std::vector<MyObject> MyCollection;
void specialCollectionInitializer(MyCollection& c, arguments...);
result specialCollectionFunction(const MyCollection& c);
etc...
Более OO способ сделать это:
typedef std::vector<MyObject> MyCollection;
class MyCollectionWrapper
{
public:
// Constructor
MyCollectionWrapper(arguments...) {construct coll_}
// Access collection directly
MyCollection& collection() {return coll_;}
const MyCollection& collection() const {return coll_;}
// Special domain-related methods
result mySpecialMethod(arguments...);
private:
MyCollection coll_;
// Other domain-specific member variables used
// in conjunction with the collection.
}