Thread: C++0x - a few doubts

Ok... I will have to digest this more. It seemed a good idea. I did feel the need a few times to build hierarchies from standard containers. Most often from std::vector. The only reason I did not was exactly the absence of dynamic binding. But truth is the item in the wish list makes no reference to virtual member functions or abstract types. Simply virtual destructors.

Originally Posted by Mario F.

How many classes are there that are built around a container only to provide the container with specific usage? Now... how many classes there are that then derive from this base class? I don't know any numbers, of course. But I feel this is not outrageous.

To be able to create hierarchies with a container as a base and to be able to redefine the container functionality, seems a natural step in a programming language that we want OO capable. Especially taking into consideration the importance the STL container objects have. Maybe not a strictly necessity, but I'm not arguing about the STL being made OO. Simply think that a new library or appending OO functionality to the STL will ease many situations.

There are basically 2 ways to get around this. The first is to derive privately from the container

Code:

#include <vector>

class Thing {};

class MyThingVector : private std::vector<Thing>
{
public:
    // expose some vector functionality
    using std::vector<Thing>::size;
    using std::vector<Thing>::reserve;

    // some custom functionality
    void AddThing(Thing& t);
};

this avoids the virtual destructor problem as MyThingVector cannot be deleted as a std vector.

the other option is containment

Code:

#include <vector>

class Thing {};

class MyThingVector
{
public:
    // expose some vector functionality
    inline size_t size(void) const { return m_vec.size(); }

    // some custom functionality
    void AddThing(Thing& t);
private:
    std::vector<Thing> m_vec;
};

This requires you to write forwarding functions. Both methods have their pros and cons

Wow, lots of stuff has happened.

So then what happens when you use auto for a non-const container? Would non-const iterator be assumed?
Yes.

Whoops, I forgot that functions can't differ only by return type. My premise here was that a non-const container can return either a const or non-const iterator from functions like begin(), and it's not the compiler's right to decide which. However, this isn't true (non-const containers don't return const iterators, right?), so my argument is unfounded.