Thread: Why does push_back, etc, not return an iterator?

By the way, its hard to tell based on your example solution, but if you are considering creating a derived container class that publicly inherits from one of the STL containers so that you can have this alternate push_back I would recommend considering a different solution. This is because, among other things, the STL containers were not designed to be publicly derived from.

I'm not really an expert in this - I am merely regurgitating things I have read elsewhere - but basically, if a class doesn't have any virtual functions (and therefore has a non-virtual destructor), then it should not be inherited from.

If you do that, then depending on how your code is used, it could lead to errors and/or undefined behavior. I believe the standard states that using delete on a pointer of a base type without a virtual destructor, whose actual dynamic type is a derived class, is undefined. For example:

Code:

#include <iostream>
#include <vector>

class BaseClass
{
public:
    BaseClass() { }
    // Non-virtual destructor
    ~BaseClass()  { std::cout << "In Base Destructor." << std::endl; }
};

class DerivedClass : public BaseClass
{
public:
    DerivedClass() { }
    // Virtual does not matter here.
    virtual ~DerivedClass() { std::cout << "In Derived Destructor." << std::endl; }
};

typedef std::vector<BaseClass*> BaseClassPtrArray;

void EmptyAndDelete(BaseClassPtrArray& objList);

int main()
{
    BaseClassPtrArray myObjList;

    myObjList.push_back(new DerivedClass);
    myObjList.push_back(new DerivedClass);

    EmptyAndDelete(myObjList);
}

void EmptyAndDelete(BaseClassPtrArray& objList)
{
    BaseClassPtrArray::iterator iterObjPtr = objList.begin();
    BaseClassPtrArray::iterator iterEnd = objList.end();
    for(; iterObjPtr != iterEnd; ++iterObjPtr)
    {
        BaseClass* pDeadObj = *iterObjPtr;
        delete pDeadObj; // Undefined behavior
    }
    objList.clear();
}

On my machine (MSVC++ 6.0 with upgraded Dinkumware libraries), the base class destructor is called and the derived class destructor is not in the default Release build. In the Debug build I get an error. Clearly, if there is anything important happening in the derived destructor, even in my Release configuration that doesn't crash, that code will not be executed.

I have seen some that have argued that they don't do anything in their derived destructor and that they "know" that a base class pointer to the derived object will never be deleted. I personally don't think that makes it any smarter, but I guess that is for you to decide.

If you only want to add functionality to the container (i.e. enhance it with new functions) then you can use containment: have a member variable of the base type and write a bunch of wrapper functions; or use global functions, possibly in a separate namespace, that take the container as template parameter. For example, something like this might work for you:

Code:

#include <iostream>
#include <vector>
#include <list>

// This is your new push_back which works with any
// push_back(), end(), and -- compatible container.
template<class C, class T>
C::iterator my_push_back(C& container, T object)
{
    container.push_back(object);
    return --container.end();
}

// Example usage:
#if 1
typedef std::vector<int> TestContainer;
#else
typedef std::list<int> TestContainer;
#endif

int main()
{
    TestContainer intArray;
    TestContainer::iterator iterPushed = my_push_back<TestContainer, int>(intArray, 1);
    if (iterPushed == intArray.begin())
        std::cout << "Success!" << std::endl;
    else
        std::cout << "Failure!" << std::endl;

    iterPushed = my_push_back<TestContainer, int>(intArray, 1);
    if (iterPushed == ++intArray.begin())
        std::cout << "Success!" << std::endl;
    else
        std::cout << "Failure!" << std::endl;
}

I used the typedefs in the example to show that you can try putting other containers in there without changing the push_back function. I'm sure there is an even better way to do that (I don't think the T template parameter is needed), but you get the idea. I believe this is the same idea used by algorithms in <algorithm>, among other things, which are nice because they work for any compatible container.

Hope that helps clarify things and hopefully if I misstated anything somebody will correct me.

Thanks CornedBee.

By the way, here is an updated version of the global push_back that doesn't require the second template parameter. It was just bugging me before so I went ahead and looked up the value_type typedef.

Code:

#include <iostream>
#include <vector>
#include <list>
#include <string>

template<class C>
C::iterator my_push_back(C& container, const C::value_type& object)
{
    container.push_back(object);
    return --container.end();
}

// Example usage:
//typedef std::vector<char> TestContainer;
//typedef std::list<char> TestContainer;
typedef std::string TestContainer;

int main()
{
    TestContainer charContainer;
    TestContainer::iterator iterPushed = my_push_back<TestContainer>(charContainer, 'j');
    if (iterPushed == charContainer.begin())
        std::cout << "Success!" << std::endl;
    else
        std::cout << "Failure!" << std::endl;
}