This investigation was set off by a warning regarding an unused argument in `SeveralBuilder`, using `AllocationPolicy::moveElem()` This warning is correct and easy to fix, but (luckily) it brought my attention to the fact that a `SeveralBuilder<Port>` can not grow dynamically, which is somewhat mitigated by the default policy to pre-allocate several elements, which would work to some degree but waste a lot of memory. This points to a deeper problem with the implementation pattern used for all those Builders: they create their product by-value, which must then be moved into the intended target location. And doing so is **extremely dangerous**, given that our very goal is to build a complex data structure internally connected by direct references and ideally also allocated with a high degree of memory locality. Unfortunately I do not see any favourable alternative yet; Ideally all products should be `NonCopyable` — but then, the builder implementation scheme would become even more complicated and less intuitive and additionally the client code would need to pre-declare the number of expected Leads and Ports (not clear if this is even feasible) |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| dump | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||