From: Gavin Lambert (boost_at_[hidden])
Date: 2019-06-28 04:40:42
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.