BDE 4.14.0 Production release
|
Typedefs | |
typedef bslma::SequentialPool | bslma_SequentialPool |
This alias is defined for backward compatibility. | |
Functions | |
void * | operator new (std::size_t size, BloombergLP::bslma::SequentialPool &pool) |
void | operator delete (void *address, BloombergLP::bslma::SequentialPool &pool) |
Provide fast variable-size memory pool with allocation methods.
This component implements a memory pool, bslma::SequentialPool
, that dispenses memory blocks of any requested size from an internal buffer or an optional user-supplied buffer. If an allocation request exceeds the remaining free memory space in the pool, the pool either replenishes its buffer with new memory to satisfy the request, or returns a separate memory block, depending on whether the request size exceeds an optionally specified maximum buffer size. By default, buffer growth is not capped. The release
method releases all memory allocated through this pool, as does the destructor. Note, however, that individual allocated blocks of memory cannot be separately deallocated.
The bslma::SequentialPool
allocates memory using one of the two alignment strategies (defined in bslma_bufferallocator ) optionally specified at construction: 1) MAXIMUM ALIGNMENT or 2) NATURAL ALIGNMENT.
bsls::AlignmentUtil::BSLS_MAX_ALIGNMENT
.int
, etc.) is naturally aligned when it's size evenly divides its address. An instance of an aggregate type has natural alignment if the alignment of the most-restrictively aligned sub-object evenly divides the address of the aggregate. Natural alignment is always at least as restrictive as the compiler's required alignment. When only the size of an aggregate is known, and not its composition, we compute the alignment by finding the largest integral power of 2 (up to and including bsls::AlignmentUtil::BSLS_MAX_ALIGNMENT
) that divides the requested (non-zero) number of bytes. This computed alignment is guaranteed to be at least as restrictive as any sub-object within the aggregate.The default strategy is NATURAL ALIGNMENT.
A buffer can be supplied to a bslma::SequentialPool
object at construction in which case the pool will try to satisfy allocation requests using this buffer before switching to a dynamically-allocated internal pool. Once the object is using an internal pool, it will not try to satisfy any subsequent allocation requests from the supplied buffer. Note that the pool does not take ownership of the buffer. Also note that bufferSize
may be specified using a positive or negative value to indicate a buffer growth strategy (see "Internal Buffer Growth").
In lieu of an externally-supplied buffer, a value for the initialSize
parameter may be supplied at construction to specify the initial size of the internal pool. If neither a buffer nor an initialSize
is specified, an implementation-defined value is used for an initial size of the internal pool. Note that initialSize
may be specified using a positive or negative value to indicate a buffer growth strategy (see "Internal Buffer Growth").
A bslma::SequentialPool
replenishes its internal buffer if the current buffer cannot satisfy an allocation request. It does so by one of two growth strategies:
Constant Growth: The new buffer is always of the same size as the current buffer (possibly supplied at construction).
Geometric Growth: The new buffer will be geometrically larger than the current buffer up to an optionally-specified maximum limit.
If a bufferSize
(and corresponding buffer
) or initialSize
is supplied at construction, the sign of its value implicitly specifies which growth strategy to use. A positive value indicates Constant Growth, whereas a a negative value indicates Geometric Growth. If neither bufferSize
nor initialSize
is supplied, Geometric Growth is used. The optional maxBufferSize
parameter may be used to place a cap on Geometric Growth (maxBufferSize
is ignored if Constant Growth is in effect). If no value is specified for maxBufferSize
, there is no cap on Geometric Growth. Note that reserveCapacity
always ensures that the requested number of bytes is available (allocating a new internal pool if necessary) irrespective of whether the size of the request exceeds maxBufferSize
.
The bslma::SequentialPool
can be used to allocate memory for containers of non-homogeneous elements, such as MyList
below. Note that the use of a sequential pool allows the operator=
and removeAll
methods to quickly deallocate memory of all elements by calling the release
method of the pool. Similarly, the destructor of MyList
simply allows the pool's destructor to deallocate memory for all elements:
|
inline |
Use the specified pool
to deallocate the memory at the specified address
. The behavior is undefined unless address
was allocated using pool
and has not already been deallocated. This operator is supplied solely to allow the compiler to arrange for it to be called in case of an exception.
|
inline |
Return the memory allocated from the specified pool
. The behavior is undefined unless size
is the same as objectSize
that pool
has been constructed with. Note that an object may allocate additional memory internally, requiring the allocator to be passed in as a constructor argument:
Note also that the analogous version of operator delete
should not be called directly. Instead, this component provides a static template member function deleteObject
parameterized by TYPE
that performs the following: