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

[Dune]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Oliver Sander (sander) 

Attached to Project - Dune
Summary - Separate GenericGeometries and the SmallObjectPool
Task Type - Bug Report
Category - Dune Modules
Status - New
Assigned To - 
Operating System - Unspecified / All
Severity - Low
Priority - Normal
Reported Version - 1.2
Due in Version - Undecided
Due Date - Undecided
Details - The generic geometries override the 'new' operator of some of its constituent classes (e.g. VirtualMapping).  This is done by inheriting from SmallObject (in dune/common/smallobject.hh), which then does memory handling through a singleton SmallObjectPool object.

This has a number of disadvantages:
- The SmallObjectPool is not thread-safe. This in itself is not a problem, but you cannot use anything else.
- It is doubtful that pool allocation is faster than stack allocation in the common case of having only
  a very small number of GenericGeometries (e.g. in UGGrid)
- SmallObjectPool does the same as PoolAllocator, but the latter is standard-conforming.

The important point is really the first one.

I see two ways to solve this problem:
a) Make the allocator type a parameter.  People that need thread-safety can then insert an appropriate allocator
b) Make everything stack-based.  People that need custom allocators can then use their favorite allocators to get
   memory and store the entire generic geometries there.

Opinions?
 

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

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.