[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)

----------
Sorry for the bad English. I meant to say that you did not mention a performance test against standard allocators, but just a performance test. As I hinted above, to test performance against standard allocators, please implement a PolyAllocator (see polyallocator.hh) that forwards all calls to a std::allocator. I consider using Markus's PoolAllocator to be the benchmark.

As for the many allocators (which you will consider useless), you are right: There are three:
1) PolyAllocator (the simplest "polymorphic" allocator just calling new / delete
2) SmallObjectPolyAllocator (which uses the small object pool internally)
3) SmallObjectAllocator (an STL allocator using the SmallObjectPool)

The SmallObjectPool itself is a helper object that is not (and never was) intended for direct use. Originally, the class SmallObject overloaded new / delete using this pool to acquire its memory. Now, there are two more allocators that use it: SmallObjectAllocator and SmallObjectPolyAllocator.

It was never my intention to keep so much stuff in this file and I think we can reduce this in the near future. I just want a fast allocator to create objects of class VirtualMapping, storing only pointers to HybridMapping. Later, I have to delete the HybridMapping. To this end, a polyallocator provides two methods:

- template< class T > T *create ( const T &value )
  create memory for an object of type T and copy construct it from value

- template< class T > void destroy ( T *p )
  delete an object of type T (or any derived type)

In order to resolve this mess (and get rid of all these allocators), I request two things:
a) implement this interface through an std::allocator (I will then adapt the GenericGeometry code accordingly, if this works out)
b) Make it work with PoolAllocator (where every copy of PoolAllocator uses the same memory pool!)
----------

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

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.