Ichthyostega
98d5b2962c
The fundamental decision is that we want to have a single generic front-end, meaning that we must jump dynamically into a configured deleter function. And on top of that comes the additional requirement that ''some allocators'' are in fact tied to a specific instance, while other allocators are monostate. However, we can distinguish both by probing if the allocator can be default constructed, and if a default constructed allocator is equivalent to the currently used alloctor instance. If this test fails, we must indeed maintain a single allocator instance, and (to avoid overengineering for this rather special use case) we will place this allocator instance into heap memory then, with a self-cleanup mechanism On the other hand, all monostate allocators can be handled through static trapolines. |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| dump | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||