This avoids potentially assigning the default to the resource value, which
may be expensive and is pointless, as the resource is about to be destroyed
anyway.
Instead of silently switching to the unique_resource implementation
based on the "allocated" flag if the resource traits don't conform
to the requirements, issue hard compilation errors. This should better
protect against mistakes, where the user assumes unique_resource
behaves as if it is using the resource traits while it actually doesn't.
Improved documentation of requirements for resource traits and documented
the "reduced" form of resource traits, where the traits only provide
the default resource value but otherwise don't change unique_resource
behavior.
One person during review complained that the library implementation
used typedefs instead of C++11 using type aliases. Not an essential
difference, but if it helps code readability, let it be.
If the resource type is nothrow move-constructible and the deleter type
is not, and the deleter's copy constructor throws during unique_resource
move constructor, then move the move-constructed resource back to the
original object instead of invoking the deleter on it. This leaves the
move source in its original state rather than in unallocated state,
which means unique_resource move constructor now provides strong
exception guarantee.
A new unallocated_resource class template allows to automatically generate
resource traits from one or more unallocated resource values.
The idea for a more compact unique_resource declaration was given
by Janko Dedic in his review.
Although it was there to make the scope guards intergace-compatible with
the TS, the review conclusion indicated that strict conformance with
the TS is not a desired goal. So remove the release() method and keep
set_active() as the way to (de)activate the scope guard.
Default- and value-constructed pointers to functions are not callable,
and therefore are not accepted as default-constructible condition
function objects and deleters.
Closes https://github.com/Lastique/scope/issues/14.
It is possible that the resource source will become moved-from after the
call to is_allocated, and that moved-from state will then be used to
initialize the resource in the resource_holder. To avoid this, don't
forward the resource source to is_allocated.
Fixes https://github.com/Lastique/scope/issues/10.
When resource_holder and deleter_holder are constructed, and resource/deleter
constructor may throw, remove forwarding the source resource/deleter to
the constructor. Forwarding there has no effect anyway, as the unique_resource
constructor already ensures the corresponding argument is passed as
an lvalue reference by using move_or_copy_construct_ref.
Also hidden these conditions from docs since they now involve symbols
from namespace detail.
Added test for noexcept(reset()).
Closes https://github.com/Lastique/scope/issues/7.
Apparently, the Library Fundamentals TS does permit pointers to functions
in scope guards (via the "function object type" definition in the standard),
so instead of taking the effort to preserve the function references decay
those to pointers to functions.
Updated docs and tests.
This reflects the decay type trait that is used in make_unique_resource_checked
and is needed to support references to functions for deleters.
Added tests for unique_resource type deductions involving references
to functions.
Scope guard factory functions used to generate scope guards with incorrect
action and condition types if the factory was called with function
references. The scope guard template arguments used to be function types
instead of references to functions.
Also, deduction guides used to decay the arguments, which would produce
scope guards with pointers to functions in template arguments. Although
this worked, formally only references to functions are supported. So
changed the deduction guides to produce references to functions.
Updated docs and tests.
Fixes https://github.com/Lastique/scope/issues/6.
As suggested by Peter Dimov on boost-dev ML, scope_check functionality
is merged into scope_exit. Thus scope_exit now has an optional condition
function object, which by default always returns true. If a custom
function object is specified, scope_exit works equivalently to the
previous scope_check, i.e. calls the condition function object to check
whether the action function object needs to be called.
Based on the boost-dev ML discussion, added a note regarding exception_checker
limitation with coroutines. Also, rearranged docs and improved wording in
a few places to make exception_checker and condition functions in general
documentation more distinct. Added rationale for using conditional scope guards
as opposed to using scope_exit universally.
The new scope_check scope guard is a generalization of scope_success and
scope_fail and allows specifying arbitrary conditions for executing the
scope exit action. The scope_success and scope_fail have been
reimplemented in terms of scope_check and now also support arbitrary
fail conditions.
Added exception_checker and error_code_checker conditions for testing
for an exception being thrown and for an error code, respectively.
scope_success and scope_fail use exception_checker by default.
Added tests for the new components.
