Можно ли наследовать реализацию от контейнеров 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.
}

Ответы на вопрос(7)

Ваш ответ на вопрос