[Dune] [#766] Separate GenericGeometries and the SmallObjectPool

[Dune]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#766 - Separate GenericGeometries and the SmallObjectPool
User who did this - Martin Nolte (nolte)

----------
I know how to construct allocators from one another. The problem is that, as far as I know, you should store the allocator as long as you use one of its objects.

As to the question what an allocator for an abstract base class is: The BasicGeometry holds a pointer to a Mapping (which is the abstract base class). Since it should store the allocator, it cannot know the type of the actuall mapping, it can at most store an allocator< Mapping > (of course, allocator< void > might be as useful).

As I said, I have not sufficient insight into the STL to understand what you can do with an allocator and what you should not do. To me, the concept seems to be tightly involved with static polymorphism, i.e., you always know the exact type of your pointer (and never only a base class). This is also reflected in the deallocate method, which wants to know the size of the object to deallocate.

My suggestion to resolve this issue remains: If it is possible to use STL allocators the way I need them, could somebody please implement  the interface or a PolyAllocator through an STL allocator? Obviously, this implementation should not bend the standard.
----------

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=766#comment1862

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.