Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-02-01 06:30:05
On 1/02/2018 19:09, Emil Dotchevski wrote:
>> The factory method technique also allows somewhat restoring a stronger
>> invariant -- only the constructor and destructor need to cope with empty or
>> otherwise uninitialised instances; other methods can be reasonably assured
>> that no such instances escaped the factory method.
> This is true only if you use exceptions to report errors from the factory.
> Otherwise it is most definitely NOT reasonable for member functions to
> assume that the object has been initialized, because nothing guarantees
> that an error reported by the factory wasn't ignored.
The factory itself provides that guarantee. One such pseudo-code
implementation might be:
static std::unique_ptr<A> A::create(args...) noexcept
// the constructor is itself noexcept and cannot fail
std::unique_ptr<A> a(new (std::nothrow) A(arg1));
if (!a->private_init_stuff(arg2, arg3, ...))
This can't return *why* it failed to create an A, but it cannot return
an invalid A, assuming that private_init_stuff always returns false if
it failed to satisfactorily init the object.
Thus any public members of A (and basically anything other than the
constructor, destructor and what is directly called from here or there)
can always assume it has a fully valid instance, whatever that means.
If you don't like the heap usage, the same concept applies if it returns
an optional instead of a pointer (assuming it has a no-fail move).
With Boost.Outcome, it can be implemented exactly as above (including
not letting an invalid instance escape), but *also* indicate a failure
reason to the caller, through a simple change to the return type.
Are exceptions cleaner and shorter? Of course. But this still works,
and some people will prefer it due to perceived latency issues with
exceptions, or just personal issues with exceptions in general, or with
"hidden code paths" expressly due to the code being shorter. (Whether
those issues are real or not, I cannot say.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk