On 28/06/2019 16:12, David Sankel wrote:
Many would prefer their PIMPL classes to not have an artificial empty/partially formed state because of the increased semantic complexity that implies.
Maybe, but that seems a bit daft to me. The whole point of move construction and assignment is to steal things from an object that's about to be thrown away -- spending time and resources to allocate more memory for it just to preserve a "never empty" state is counterproductive in that scenario. Granted that in the case where someone misbehaves and does try to use an invalid operation on an empty object (ie. anything other than assignment, destruction, or empty()/explicit bool/whatever), people like neither the wide interface of empty checks in each public method nor the implementation-defined-behaviour of accessing a null pointer -- but at least on most platforms the latter is reasonably guaranteed to crash immediately rather than having any other adverse effect, so it seems like the lesser of all evils to me. Just accept that it can be empty, and that your program will crash if you do something inappropriate with an empty object. No reason to introduce a "never empty" invariant where it will harm performance.