There are three general components to the allocator: a datum describing the characteristics of the memory pool, a policy class containing this pool that links instantiation types to common or individual pools, and a class inheriting from the policy class that is the actual allocator.
The datum describing pools characteristics is
template<bool _Thread>
class __pool
This class is parametrized on thread support, and is explicitly
specialized for both multiple threads (with bool==true)
and single threads (via bool==false.) It is possible to
use a custom pool datum instead of the default class that is provided.
There are two distinct policy classes, each of which can be used with either type of underlying pool datum.
template<bool _Thread>
struct __common_pool_policy
template<typename _Tp, bool _Thread>
struct __per_type_pool_policy
The first policy, __common_pool_policy, implements a
common pool. This means that allocators that are instantiated with
different types, say char and long will both
use the same pool. This is the default policy.
The second policy, __per_type_pool_policy, implements
a separate pool for each instantiating type. Thus, char
and long will use separate pools. This allows per-type
tuning, for instance.
Putting this all together, the actual allocator class is
template<typename _Tp, typename _Poolp = __default_policy>
class __mt_alloc : public __mt_alloc_base<_Tp>, _Poolp
This class has the interface required for standard library allocator
classes, namely member functions allocate and
deallocate, plus others.
There are three general components to the allocator: a datum @ 1.1.1.1.28.1 log @Sync with HEAD, resolve a couple of conflicts @ text @d2 1 a2 1
There are three general components to the allocator: a datum @ 1.1.1.2 log @import GCC 6.5.0. this is largely a maint release with no particularly features listed here: http://gcc.gnu.org/gcc-6/changes.html this fixes over 250 PRs in the GCC bugzilla: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.5 @ text @d2 1 a2 1
There are three general components to the allocator: a datum @ 1.1.1.3 log @initial import of GCC 10.3.0. main changes include: caveats: - ABI issue between c++14 and c++17 fixed - profile mode is removed from libstdc++ - -fno-common is now the default new features: - new flags -fallocation-dce, -fprofile-partial-training, -fprofile-reproducible, -fprofile-prefix-path, and -fanalyzer - many new compile and link time optimisations - enhanced drive optimisations - openacc 2.6 support - openmp 5.0 features - new warnings: -Wstring-compare and -Wzero-length-bounds - extended warnings: -Warray-bounds, -Wformat-overflow, -Wrestrict, -Wreturn-local-addr, -Wstringop-overflow, -Warith-conversion, -Wmismatched-tags, and -Wredundant-tags - some likely C2X features implemented - more C++20 implemented - many new arm & intel CPUs known hundreds of reported bugs are fixed. full list of changes can be found at: https://gcc.gnu.org/gcc-10/changes.html @ text @d2 1 a2 1
There are three general components to the allocator: a datum describing the characteristics of the memory pool, a policy class containing this pool that links instantiation types to common or individual pools, and a class inheriting from the policy class that is the actual allocator.
The datum describing pools characteristics is
template<bool _Thread>
class __pool
This class is parametrized on thread support, and is explicitly
specialized for both multiple threads (with bool==true)
and single threads (via bool==false.) It is possible to
use a custom pool datum instead of the default class that is provided.
There are two distinct policy classes, each of which can be used with either type of underlying pool datum.
template<bool _Thread>
struct __common_pool_policy
template<typename _Tp, bool _Thread>
struct __per_type_pool_policy
The first policy, __common_pool_policy, implements a
common pool. This means that allocators that are instantiated with
different types, say char and long will both
use the same pool. This is the default policy.
The second policy, __per_type_pool_policy, implements
a separate pool for each instantiating type. Thus, char
and long will use separate pools. This allows per-type
tuning, for instance.
Putting this all together, the actual allocator class is
template<typename _Tp, typename _Poolp = __default_policy>
class __mt_alloc : public __mt_alloc_base<_Tp>, _Poolp
This class has the interface required for standard library allocator
classes, namely member functions allocate and
deallocate, plus others.
There are three general components to the allocator: a datum describing the characteristics of the memory pool, a policy class containing this pool that links instantiation types to common or individual pools, and a class inheriting from the policy class that is the actual allocator.
The datum describing pools characteristics is
template<bool _Thread>
class __pool
This class is parametrized on thread support, and is explicitly
specialized for both multiple threads (with bool==true)
and single threads (via bool==false.) It is possible to
use a custom pool datum instead of the default class that is provided.
There are two distinct policy classes, each of which can be used with either type of underlying pool datum.
template<bool _Thread>
struct __common_pool_policy
template<typename _Tp, bool _Thread>
struct __per_type_pool_policy
The first policy, __common_pool_policy, implements a
common pool. This means that allocators that are instantiated with
different types, say char and long will both
use the same pool. This is the default policy.
The second policy, __per_type_pool_policy, implements
a separate pool for each instantiating type. Thus, char
and long will use separate pools. This allows per-type
tuning, for instance.
Putting this all together, the actual allocator class is
template<typename _Tp, typename _Poolp = __default_policy>
class __mt_alloc : public __mt_alloc_base<_Tp>, _Poolp
This class has the interface required for standard library allocator
classes, namely member functions allocate and
deallocate, plus others.