preliminary solution for critical allocations

[Ichthyostega]

As a Lumiera developer,
I need a way to deal with performance critical allocations,
without being able to develop a custom allocation scheme at the current stage of development.

explanation

At some places, frequent allocations are expected to happen within a potentially performance critical context, which can neither be managed by ref-count, nor can this situation handled as bulk allocation. We should use the allocator of the standard library explicitly for those cases, yet introduce a custom marker interface, trait or concept, so that these usages can be considered for custom allocation handling later.

[Ichthyostega]

consider that settled for now...

• wrote a front-end to simplify the most common case, which is placement-new
• policy based design. Use just std::allocator as policy for now, which means heap allocations

see #835 for the remaining work

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin

[Ichthyostega]

re-open

Over the last years,
I developed some kind of pattern to mark such cases with a special-case allocator class, that is aligned with our prospective custom allocator concept (#1366) — even while this concept is not fully established yet. Examples of that pattern can be seen in the BlockFlow and for the lib::Several allocator backend.

None of this is completed or settled in any way however, and thus I'm re-opening this ticket again. The point is not just to make a heap allocation as preliminary solution, and »policy based design« alone won't cut it — because the question is then what allocator type to place into said policy...

• an Allocator provides raw memory allocations (and is composable)
• a Factory creates objects based on an Allocator
• a Handle packages the product in such a way that de-allocation can be automated