...this extension was spurred by the previeous refactoring. Since 'emplace' now clearly denotes an operation to move-embed an existing object, we could as well offer a separate 'create' API, which would take forwarding arguments as usual and just delegates to the placement-new operation 'create' already available in the InPlaceBuffer class. Such would be a convenience shortcut and is not strictly necessary, since move-construction is typically optimised away; yet it would also allow to support strictly non-copyable payload types. This refactoring also highlights a fuzziness in the existing design, where we just passed the interface type, while being sloppy about the DEFAULT type. In fact this *is* relevant, since any kind of construction might fail, necessitating to default-construct a placeholder, since InPlaceBuffer was intended for zero-overhead usage and thus has in itself no means to know about the state of its buffer's contents. Thus the only sane contract is that there is always a valid object emplaced into the buffer, which in turn forces us to provide a loophole for class hierarchies with an abstract base class -- in such a case the user has to provide a fallback type explicitly. |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||