allocator_delete does not support polymorphism

[twiggler]

Cannot convert
std::unique_ptr<Game::KillShip, foonathan::memory::allocator_deleter<Game::KillShip, foonathan::memory::temporary_allocator, std::mutex>>
TO
std::unique_ptr<Game::EntityCommand, foonathan::memory::allocator_deleter<Game::EntityCommand, foonathan::memory::temporary_allocator, std::mutex>

where Game::EntityCommand is the base class of Game::KillShip

[foonathan]

I can't really implement it, because deallocation of custom allocators is not polymorphic.

You see, when deallocating an object I need to know its size, which I don't know for a base class.
It only works for new and delete because they are built-in language features and can do magic (for example, the destructor could return sizeof(*this)).

What I could add is a allocator_polymorphic_deleter that stores the size as an additional member variable but this has overhead. Would that work for you?

I'm assuming you're having a container of unique_ptr<Base> and want to put derived classes in it? This is not necessarily good design as all memory::unique_ptr store a reference to an allocator, even though they may just be allocated from the same one. Something like a ptr_vector that stores only one reference allocator would be more efficient anyway.

[twiggler]

If I understand ptr_vector allocator correctly, it uses the clonable concept to deallocate objects in the container. This concept has no notion of the size of elements, so I cannot glue in a raw allocator. I am willing to incur the wasted memory caused by the allocator references as long as it performs better in time than the standard allocator. So for my purposes, storing the size in the deleter is probably acceptable. The alternative would be a variant of commands, but in this case I am willing to incur the virtual function call overhead to get extensibility.

[twiggler]

Thanks!