C++ Vectors, Lists, Pointers, and Confusion

Question 1

As I understand it, you're doing something like this:

cow florence, buttercup;
std::vector<cow> v = { florence, buttercup };
cow* buttercup_ptr = &v[1];

// do something involving the cow*

And your buttercup_ptr is getting invalidated because, eg. florence was removed from the vector.

It is possible to resolve this by using smart pointers, like this:

std::shared_ptr<cow> florence = std::make_shared<cow>();
std::vector<std::shared_ptr<cow>> v;
v.push_back(florence);

You can now freely share florence... regardles off how the vector gets shuffled around, it remains valid.

If you want to let florence be destroyed when you pop her out of the vector, that presents a minor problem: anyone holding a copy of the shared_ptr will prevent this particular cow instance being cleaned up. You can avoid that by using a weak_ptr.

std::weak_ptr<cow> florence_ref = florence;

In order to use a weak_ptr you call lock() on it to convert it to a full shared_ptr. If the underlying cow instance was already destroyed because it had no strong references, an excetion is throw (you can also call expired() to check this before lock(), of course!)

The other possibility (as I suggested in my comment on the original question) is to use iterators pointing into the container holding the cow instances. This is a little stranger, but iterators are quite like pointers in many ways. You just have to be careful in your choice of container, to ensure your iterators aren't going to be invalidate (which mean syou can't use a vector for this purpose);

std::set<cow> s;
cow florence;
auto iter = s.insert(florence);

// do something with iter, and not worry if other cows are added to
// or removed from s

I don't think I'd necessarily advise this option, though I'm sure it would work. Using smart pointers is a better way to show future maintainance programmers your intent and has the advantage that getting dangling references is much harder.

Question 2

You have a misconception about pointers. A pointer is (for the sake of this discussion!) just an address. Why would copying an address invalidate anything? Let's say your object is created in memory at address 12345. new therefore gives you a pointer whose value is 12345:

Entity *entity = new Cow; // object created at address 12345
// entity now has value 12345

Later, when you copy that pointer into a vector (or any other standard container), you copy nothing but the value 12345.

std::vector<Entity *> entities;
entities.push_back(entity);
// entities[0] now has value 12345, entity does not change and remains 12345

In fact, there's no difference with regards to this compared to, say, a std::vector<int>:

int i = 12345;
std::vector<int> ints;
ints.push_back(i);
// ints[0] now has value 12345, i does not change and remains 12345

When the vector is copied, the values inside do not change, either:

std::vector<int> ints2 = ints;
std::vector<Entity *> entities2 = entities;
// i, ints[0] and ints[0] are 12345
// entity, entities[0] and entities[0] are 12345

So if a Pig has a relationship with a cow and the cow vector is resized, the Pig loses track of where its friend is located in memory & has a dangerous incorrect pointer.

This fear is unfounded. The Pig does not lose track of its friend.

The dangerous thing is keeping a pointer to a deleted object:

delete entity;
entities[0]->doSometing(); // undefined behaviour, may crash

How to solve this problem is subject of thousands of questions, websites, blogs and books in C++. Smart pointers may help you, but you should first truly understand the concept of ownership.

Question 3

My two cent. The code below is a working example (C++11, translates with g++ 4.8.2) with smart pointers and factory function create. Should be quite failsafe. (You can always destroy something in C++ if you really want to.)

#include <memory>
#include <vector>
#include <algorithm>
#include <iostream>
#include <sstream>

class Entity;


typedef std::shared_ptr<Entity> ptr_t;
typedef std::vector<ptr_t> animals_t;

class Entity {
protected:
    Entity() {};
public:
    template<class E, typename... Arglist>
    friend ptr_t create(Arglist... args) {
        return ptr_t(new E(args...));
    }

    animals_t my_friends;

    virtual std::string what()=0;
};

class Cow : public Entity {
    double m_milk;
    Cow(double milk) :
        Entity(),
        m_milk(milk)
    {}
public:
    friend ptr_t create<Cow>(double);

    std::string what() {
        std::ostringstream os;
        os << "I am a cow.\nMy mother gave " << m_milk << " liters.";
        return os.str();
    }
};

class Pig : public Entity {
    Pig() : Entity() {}
public:
    friend ptr_t create<Pig>();

    std::string what() {
        return "I am a pig.";
    }
};

int main() {
    animals_t animals;

    animals.push_back(create<Cow>(1000.0));
    animals.push_back(create<Pig>());

    animals[0]->my_friends.push_back(animals[1]);

    std::for_each(animals.begin(),animals.end(),[](ptr_t v){
            std::cout << '\n' << v->what();
            std::cout << "\nMy friends are:";
            std::for_each(v->my_friends.begin(),v->my_friends.end(),[](ptr_t f){
                    std::cout << '\n' << f->what();
                });
            std::cout << '\n';
        });
}

/*
    Local Variables:
    compile-command: "g++ -std=c++11 test.cc -o a.exe && ./a.exe"
    End:
 */

By declaring the Entity constructor as protected one forces that derived objects of type Entity must be created through the factory function create.

The factory makes sure that objects always to into smart pointers (in our case std::shared_ptr).

It is written as template to make it re-usable in the subclasses. More precisely it is a variadic template to allow constructors with any numbers of arguments in the derived classes. In the modified version of the program one passes the milk production of the mother cow to the newly created cow as a constructor argument.