Home/ Questions/Q 6375219
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T01:35:16+00:00

EDIT: A better title for this would be: polymorphism for large collections of objects

  • 0

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;
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?

    • 0