BDE 4.14.0 Production release
|
Provide a proctor to conditionally manage an object.
This component provides a proctor class template, bslma::RawDeleterProctor
, to conditionally manage an (otherwise-unmanaged) object of parameterized TYPE
supplied at construction. If not explicitly released, the managed object is deleted automatically when the proctor object goes out of scope by first calling the (managed) object's destructor, and then freeing the memory using the parameterized ALLOCATOR
(allocator or pool) also supplied at construction. Note that after a proctor object releases its managed object, the same proctor can be reused to conditionally manage another object (allocated from the same allocator or pool that was supplied at construction) by invoking the reset
method.
Note that this component should be used only if we are sure that the supplied pointer is not of a type that is a secondary base class – i.e., the (managed) object's address is (numerically) the same as when it was originally dispensed by ALLOCATOR
.
The parameterized ALLOCATOR
type of the bslma::RawDeleterProctor
class template must provide a (possibly virtual
) method:
to deallocate memory at the specified address
(originally supplied by the ALLOCATOR
object).
bslma::RawDeleterProctor
is normally used to achieve exception safety in an exception neutral way by managing objects that are created temporarily on the heap, but not yet committed to a container object's management. This (somewhat contrived) example illustrates the use of a bslma::RawDeleterProctor
to manage a dynamically-allocated object, deleting the object automatically should an exception occur.
Suppose we have a simple linked list class that manages objects of parameterized TYPE
, but which are (for the purpose of this example) allocated separately from the links that hold them (thereby requiring two separate allocations for each append
operation):
Note that the rest of the my_List
interface (above) and implementation (below) are omitted as the portion shown is sufficient to demonstrate the use of bslma::RawDeleterProctor
.
The append
method defined above potentially throws in three places. If the memory allocator held in d_allocator_p
were to throw while attempting to create the object of parameterized TYPE
, no memory would be leaked. But without subsequent use of the bslma::RawDeleterProctor
, if the allocator subsequently throws while creating the link, all memory (and any other resources) acquired as a result of copying the (not-yet-managed) object would be leaked. Using the bslma::RawDeleterProctor
prevents the leaks by deleting the proctored object automatically should the proctor go out of scope before the release
method of the proctor is called (such as when the function exits prematurely due to an exception).
Note that the append
method assumes the copy constructor of TYPE
takes an allocator as a second argument. In production code, a constructor proxy that checks the traits of TYPE
(to determine whether TYPE
uses bslma::Allocator
) should be used (see bslalg_constructorproxy ).