#include <bdlma_guardingallocator.h>
Public Types | |
| enum | GuardPageLocation { e_AFTER_USER_BLOCK, e_BEFORE_USER_BLOCK } |
| typedef bsls::Types::size_type | size_type |
Public Member Functions | |
| GuardingAllocator (GuardPageLocation guardLocation=e_AFTER_USER_BLOCK) | |
| virtual | ~GuardingAllocator () |
| virtual void * | allocate (bsls::Types::size_type size) |
| virtual void | deallocate (void *address) |
| virtual void * | allocate (size_type size)=0 |
| template<class TYPE > | |
| void | deleteObject (const TYPE *object) |
| void | deleteObject (bsl::nullptr_t) |
| template<class TYPE > | |
| void | deleteObjectRaw (const TYPE *object) |
| void | deleteObjectRaw (bsl::nullptr_t) |
Static Public Member Functions | |
| static void | throwBadAlloc () |
Detailed Description
This class defines a concrete thread-safe "guarding" allocator mechanism that implements the bslma::Allocator protocol, and adjoins a read/write protected guard page to each block of memory returned by the allocate method. The guard page is placed immediately before or immediately following the block returned from allocate according to the GuardPageLocation enumerator value (optionally) supplied at construction. Note that, unlike many other allocators, an allocator cannot be (optionally) supplied at construction; instead, a system facility is used that allocates blocks of memory in multiples of the system page size. Also note that this allocator is intended for debugging purposes only.
See Component bdlma_guardingallocator
Member Typedef Documentation
typedef bsls::Types::size_type bslma::Allocator::size_type [inherited] |
Reimplemented in bdlma::ConcurrentPoolAllocator.
Member Enumeration Documentation
Enumerate the configuration options for GuardingAllocator that may be (optionally) supplied at construction.
Constructor & Destructor Documentation
| bdlma::GuardingAllocator::GuardingAllocator | ( | GuardPageLocation | guardLocation = e_AFTER_USER_BLOCK |
) | [explicit] |
Create a guarding allocator. Optionally specify a guardLocation indicating where read/write protected guard pages should be placed with respect to the memory blocks returned by the allocate method. If guardLocation is not specified, guard pages are placed immediately following the memory blocks returned by allocate.
| virtual bdlma::GuardingAllocator::~GuardingAllocator | ( | ) | [virtual] |
Destroy this allocator object. Note that destroying this allocator has no effect on any outstanding allocated memory.
Member Function Documentation
| virtual void* bdlma::GuardingAllocator::allocate | ( | bsls::Types::size_type | size | ) | [virtual] |
Return a newly-allocated maximally-aligned block of memory of the specified size (in bytes) that has a read/write protected guard page located immediately before or after it according to the GuardPageLocation indicated at construction. If size is 0, no memory is allocated and 0 is returned. Note that a multiple of the platform's memory page size is allocated for every call to this method.
| virtual void bdlma::GuardingAllocator::deallocate | ( | void * | address | ) | [virtual] |
Return the memory block at the specified address back to this allocator. If address is 0, this method has no effect. Otherwise, the guard page associated with address is unprotected and also deallocated. The behavior is undefined unless address was returned by allocate and has not already been deallocated.
Implements bslma::Allocator.
| static void bslma::Allocator::throwBadAlloc | ( | ) | [static, inherited] |
DEPRECATED: Use bsls::BslExceptionUtil::throwBadAlloc instead.
Throw std::bad_alloc if exceptions are enabled or abort the program otherwise. Derived classes and helper functions will typically call this function when they are unable to satisfy an allocation request. This function never returns.
| virtual void* bslma::Allocator::allocate | ( | size_type | size | ) | [pure virtual, inherited] |
Return a newly allocated block of memory of (at least) the specified positive size (in bytes). If size is 0, a null pointer is returned with no other effect. If this allocator cannot return the requested number of bytes, then it will throw a std::bad_alloc exception in an exception-enabled build, or else will abort the program in a non-exception build. The behavior is undefined unless 0 <= size. Note that the alignment of the address returned conforms to the platform requirement for any object of the specified size.
Implemented in ball::CountingAllocator, balst::StackTraceTestAllocator, bdlma::BufferedSequentialAllocator, bslma::AllocatorAdaptor_Imp< STL_ALLOC >, bslma::BufferAllocator, bslma::MallocFreeAllocator, bslma::NewDeleteAllocator, bslma::SequentialAllocator, bslma::TestAllocator, and bslma::AllocatorAdaptor_Imp< STL_ALLOC::template rebind< char >::other >.
| void bslma::Allocator::deleteObject | ( | const TYPE * | object | ) | [inherited] |
Destroy the specified object based on its dynamic type and then use this allocator to deallocate its memory footprint. Do nothing if object is a null pointer. The behavior is undefined unless object, when cast appropriately to void *, was allocated using this allocator and has not already been deallocated. Note that dynamic_cast<void *>(object) is applied if TYPE is polymorphic, and static_cast<void *>(object) is applied otherwise.
| void bslma::Allocator::deleteObject | ( | bsl::nullptr_t | ) | [inherited] |
This function has no effect. Note that it exists to support calling deleteObject will a null pointer literal, that would otherwise not deduce to a pointer type for the method above. As calls to deleteObject with (typed) null pointer values have well-defined behavior, it should also support calls with a null pointer literal.
| void bslma::Allocator::deleteObjectRaw | ( | const TYPE * | object | ) | [inherited] |
Destroy the specified object and then use this allocator to deallocate its memory footprint. Do nothing if object is a null pointer. The behavior is undefined unless object was allocated using this allocator, is not a secondary base class pointer -- i.e., the address is (numerically) the same as when it was originally dispensed by this allocator, and has not already been deallocated.
| void bslma::Allocator::deleteObjectRaw | ( | bsl::nullptr_t | ) | [inherited] |
This function has no effect. Note that it exists to support calling deleteObjectRaw will a null pointer literal, that would otherwise not deduce to a pointer type for the method above. As calls to deleteObjectRaw with (typed) null pointer values have well-defined behavior, it should also support calls with a null pointer literal.
The documentation for this class was generated from the following file:
Generated on Fri Mar 31 2023 13:28:11 for BDE Release 3.115.0.0 Production Release by
1.7.1