CODEWITHSUNDEEP
c++memory-managementpolymorphismdynamic-memory-allocation
Andrei Bozantan
Andrei Bozantan

Reputation: 3921

C++ polymorphism without pointers

EDIT: A better title for this would be: polymorphism for large collections of objects without individual heap allocations.

Suppose that I have a base class Animal with virtual functions and some derived classes (Cat, Dog, etc.). The real derived classes contain 4-8 bytes of data. I want to store a std::list<Animal> which actually contains items which are derived objects. I want to avoid the creation of many small objects on the heap using new.

Is there any design pattern which can be used to achieve this?

EDIT: My ideas to implement this

  1. create std::deque<Cat>, std::deque<Dog>, ...; store std::list<Animal*> which contains pointers from the deques; I use the std::deque because I suppose that it has a good memory management with chunks of objects;

Upvotes: 48

Views: 34080

Answers (5)

Raven
Raven

Reputation: 3516

This is a follow-up on the suggestion to use a variant (be it Boost's or the one from the STL since cxx17), if all possible child-classes are known at compile time (this case is also known as "closed-set polymorphism").

Having to use the visitor pattern to access your object's interface is a bit annoying (imo), which is why I have written a variant-type that exposes the base-class interface (and even the base-type operators). It can be found at https://github.com/Krzmbrzl/polymorphic_variant (requires C++17 as it is built around std::variant).

Cloning the example from @Draziv:

Class-definitions

class Animal {
public:
    virtual void eat() = 0;
};

class Cat : public Animal {
    virtual void eat() final override {
        std::cout << "Mmh, tasty fish!" << std::endl;
    }
};

class Dog: public Animal {
    virtual void eat() final override {
        std::cout << "Mmh, tasty bone!" << std::endl;
    }
};

Example usage

pv::polymorphic_variant< Animal, Dog, Cat > variant;
variant->eat();

variant = Cat{};
variant->eat();

Output:

Mmh, tasty bone!
Mmh, tasty fish!

Upvotes: 1

Draziw
Draziw

Reputation: 91

I realize that this question is old, but I found a somewhat pretty solution.

Assumption:

You know all the derived classes in advance (given your edit, this is true).

Trick:

Using boost::variant (http://www.boost.org/doc/libs/1_57_0/doc/html/variant.html)

Example classes:

class Animal {
public:
    virtual void eat() = 0;
};

class Cat : public Animal {
    virtual void eat() final override {
        std::cout << "Mmh, tasty fish!" << std::endl;
    }
};

class Dog: public Animal {
    virtual void eat() final override {
        std::cout << "Mmh, tasty bone!" << std::endl;
    }
};

Example variant/visitor:

typedef boost::variant<Cat, Dog> AnimalVariant;

class AnimalVisitor : public boost::static_visitor<Animal&> {
public:
    Animal& operator()(Cat& a) const {
        return a;
    }

    Animal& operator()(Dog& a) const {
        return a;
    }
};

Example usage:

std::vector<AnimalVariant> list;
list.push_back(Dog());
list.emplace_back(Cat());

for(int i = 0; i < 5; i++) {
    for(auto& v : list) {
        Animal& a = v.apply_visitor(AnimalVisitor());
        a.eat();
    }
}

Example output

Mmh, tasty bone!
Mmh, tasty fish!
Mmh, tasty bone!
Mmh, tasty fish!
Mmh, tasty bone!
Mmh, tasty fish!
Mmh, tasty bone!
Mmh, tasty fish!
Mmh, tasty bone!
Mmh, tasty fish!

Upvotes: 9

Brian Coleman
Brian Coleman

Reputation: 1070

If you're worried about allocating many small heap objects, then a vector may be a better choice of container rather than a list and a deque. list will allocate a node on the heap each time that you insert an object into the list, whereas vector will store all objects in a contiguous region of memory on the heap.

If you have:

std::vector<Dog> dogs;
std::vector<Cat> cats;

std::vector<Animal*> animals;

void addDog(Dog& dog, std::vector<Dog>& dogs, std::vector<Animal*>& animals) {
  dogs.push_back(dog);
  animals.push_back(&dog);
}

Then all dogs and cats are stored in two contiguous region of memory on the heap.

Upvotes: 2

soru
soru

Reputation: 5526

You probably could do something with a simple wrapper class for a union containing the super-set of data needed by every case. This would contain a pointer to shared strategy objects that contained the code for the different behaviours. So a cat is an object of class PolyAnimal with speciesName = "cat", a PredatorFeedingStrategy and so on.

Likely a better way of solving the underlying problem is setting up appropriate custom allocators for a more natural design.

Upvotes: 0

Nicol Bolas
Nicol Bolas

Reputation: 473312

Ultimately, no.

Polymorphism only works with non-value types: references and pointers. And since references can only be bound once, you cannot really use them in standard containers. That leaves you with pointers.

You're attacking the problem at the wrong end. If you are concerned about the overhead of allocating lots of small objects (and I'm assuming that this is a legitimate concern. That is, you have actual profiling data or sufficient experience to know it is a concern for your specific application), then you should fix that. Change how you're allocating memory for these objects. Make a small allocation heap or something.

Admittedly, pre-C++0x's allocators are somewhat lacking in this regard, since they have to be stateless. But for your purposes, you should be able to deal with it.

From your edit:

That is a terrible idea. Erasing from a std::deque at anywhere but the start or end will invalidate every pointer in your std::list.

Given your comment, this idea is functional. However, having all of these different memory blocks for different kinds of objects seems to go against the whole point of inheritance. After all, you can't just write a new type of Animal and slip it into the std::list; you have to provide memory management for it.

Are you sure that inheritance-based polymorphism is what you need here? Are you sure that some other methodology would not work just as well?

Upvotes: 44

Related Questions