Wrapping STL in order to extend - c++

Question

So I read that inheritance from STL is a bad idea. But what about wrapping STL classes inside other classes in order to extend them. This with the main purpose of separating levels of abstraction, among other things.
Something like:
template<class T>
class MyVector{
public:
T& last(){
return data[data.size() - 1]
}
bool include(T& element);
//etc.
private:
vector<T> data;
}
Is this a good idea? Is this something c++ programmers do often?
Thank you.

Answer 1

Yes, wrapping is better than inheritance, but only if you need to add state to an existing data structure. Otherwise, add non-member functions. This is explained in more detail in item 35 of C++ Coding Standards (Amazon)
To add state, prefer composition instead of inheritance. Admittedly, it's tedious to have to write passthrough functions for the member functions
you want to keep, but such an implementation is vastly better and safer than
using public or nonpublic inheritance.
template<typename T>
class MyExtendedVector
{
public:
// pass-through functions for std::vector members
void some_existing_fun() { return vec_.some_existing_fun(); }
// new functionality that uses extra state
void some_new_fun() { // your implementation here }
private:
std::vector<T> vec_;
// extra state e.g. to do logging, caching, or whatever
};
To add behavior, prefer to add nonmem-ber functions instead of member
functions.
However make sure to make your algorithms as generic as possible:
// if you CAN: write algorithm that uses iterators only
// (and delegates to iterator category that container supports)
template<typename Iterator, typename T>
bool generic_contains(Iterator first, Iterator last, T const& elem)
{
// implement using iterators + STL algorithms only
return std::find(first, last, elem) != last;
}
// if you MUST: write algorithm that uses specific interface of container
template<typename T>
void vector_contains(std::vector<T> const& v, T const& elem)
{
// implement using public interface of Container + STL algorithms
return generic_contains(v.begin(), v.end(), elem);
}

Answer 2

I can only speak for myself but I haven't done this, and I probably wouldn't suggest it in general.
In almost every case an iterator-based algorithm is simpler to implement and separates the algorithm from the container. For example, assuming that your include method is simply to determine if an element is in the vector you would use either find, binary_search, or lower_bound depending on your container's contents and search needs.
Occasionally I have implemented a class that looks like a container to the outside world by providing begin/end methods. In this case it sometimes does have a standard container underlying, but you only implement a minimal public interface to represent what your class actually models.

Answer 3

I would avoid doing this, as the last person replied. I understand where you are going where you want your container to wrap some of the more complex operations into simplier methods and are thinking that you could change the underlying container at some point without having to change your interfaces. However, having said that, your object should model your business requirements and then the implementation of those objects would use whatever data container and access patterns are best. I guess what I am saying is that you won't end up re-using this new vector class as the data access of your business requirements will be different each time and you will use a some standard generic container like std::vector again and the iterator based algos to access the data.
Now if there is some algo that doesn't exist, you can write that iterator based algo for that specific project and then keep that algo code which you may be able to re-use. Below shows a set grep algo that I wrote that was based on a set intersection but wasn't doing exactly what I wanted. I could reuse this algo another time.
#include <utility>
#include <algorithm>
// this is a set grep meaning any items that are in set one
// will be pulled out if they match anything in set 2 based on operator pred
template<typename _InputIterator1, typename _InputIterator2,
typename _OutputIterator, typename _Compare>
_OutputIterator
setGrep(_InputIterator1 __first1, _InputIterator1 __last1,
_InputIterator2 __first2, _InputIterator2 __last2,
_OutputIterator __result, _Compare __comp)
{
while (__first1 != __last1 && __first2 != __last2)
if (__comp(*__first1, *__first2))
++__first1;
else if (__comp(*__first2, *__first1))
++__first2;
else
{
*__result = *__first1;
++__first1;
++__result;
}
return __result;
}