The library is based heavily on policy-based design and uses many useful
-techniques from [alexandrescu01modern].
-
-
Two ideas are borrowed from the SGI-STL implementation [sgi_stl]:
-
-
- The prime-based resize policies use a list of primes taken from the SGI-STL implementation.
-
-
The red-black trees contain both a root node and a header
- node (containing metadata), connected in a way
- that forward and reverse iteration can be performed efficiently.
-
-
-
-
Some test utilities borrow ideas from [boost_timer].
-
-
We would like to thank Scott Meyers for useful comments (without attributing to him
- any flaws in the design or implementation of the library).
-
Inserts a value_type object. If no value_type with r_val's key was in the container object, inserts and returns (find_iterator object associated with r_val, true); otherwise just returns (find_iterator object associated with r_val's key, false).
Erases the value_type associated with r_key; returns the number of value_types erased (0 or 1).
-
-
-
-
-
-
-
-
-
template<
- class Pred>
-inlinesize_type
- erase_if
- (Pred prd)
-
-
-
-
-
-
Erases any value_type satisfying the predicate prd (this is transactional, either all matching value_types are erased, or, if an exception is thrown (for types whose erase can throw an exception) none); returns the number of value_types erased.
Inserts a value_type object. If no value_type with r_val's key was in the container object, inserts and returns (find_iterator object associated with r_val, true); otherwise just returns (find_iterator object associated with r_val's key, false).
Erases the value_type associated with r_key; returns the number of value_types erased (0 or 1).
-
-
-
-
-
-
-
-
-
template<
- class Pred>
-inlinesize_type
- erase_if
- (Pred prd)
-
-
-
-
-
-
Erases any value_type satisfying the predicate prd (this is transactional, either all matching value_types are erased, or, if an exception is thrown (for types whose erase can throw an exception) none); returns the number of value_types erased.
Inserts a value_type object. If no value_type with r_val's key was in the container object, inserts and returns (find_iterator object associated with r_val, true); otherwise just returns (find_iterator object associated with r_val's key, false).
Erases the value_type associated with r_key; returns the number of value_types erased (0 or 1).
-
-
-
-
-
-
-
-
-
template<
- class Pred>
-inlinesize_type
- erase_if
- (Pred prd)
-
-
-
-
-
-
Erases any value_type satisfying the predicate prd (this is transactional, either all matching value_types are erased, or, if an exception is thrown (for types whose erase can throw an exception) none); returns the number of value_types erased.
Signifies a basic invalidation guarantee that any iterator, pointer, or reference to a container object's mapped value type is valid as long as the container is not modified.
-
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, and r_eq_fn will be copied by the Eq_Fn object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, and r_comb_hash_fn will be copied by the Comb_Hash_Fn object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, r_comb_hash_fn will be copied by the Comb_Hash_Fn object of the container object, and r_resize_policy will be copied by the Resize_Policy object of the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- cc_hash_assoc_cntnr
- (It first_it,
- It last_it)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types. The value_types between first_it and last_it will be inserted into the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- cc_hash_assoc_cntnr
- (It first_it,
- It last_it,
- constHash_Fn &r_hash_fn)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- cc_hash_assoc_cntnr
- (It first_it,
- It last_it,
- constHash_Fn &r_hash_fn,
- constEq_Fn &r_eq_fn)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types and some policy objects The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, and r_eq_fn will be copied by the Eq_Fn object of the container object.
Constructor taking iterators to a range of value_types and some policy objects The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, and r_comb_hash_fn will be copied by the Comb_Hash_Fn object of the container object.
Constructor taking iterators to a range of value_types and some policy objects The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, r_comb_hash_fn will be copied by the Comb_Hash_Fn object of the container object, and r_resize_policy will be copied by the Resize_Policy object of the container object.
Specifies whether the load factor can be accessed externally. The two options have different tradeoffs in terms of flexibility, genericity, and encapsulation.
- Associative containers are typically parameterized by various policies.
-For example, a hash-based associative
-container is parameterized by a hash-functor, transforming each key into an non-negative numerical type. Each such value is then further mapped into a position within the table.
-The mapping of a key into a position within the table is therefore a two-step process.
-
-
-
-In some
-cases, instantiations are redundant. For example, when the keys are integers, it is possible to use a redundant
-hash policy, which transforms each key into its value.
-
-
-
- In some other cases, these policies are irrelevent. For example,
-a hash-based associative container might transform keys into positions within
-a table by a different method than the two-step method described above. In such a case, the hash functor is simply irrelevent.
-
-
-
- pb_assoc uses special pre-defined "null policies" classes
-for these cases. Some null policies in pb_assoc
-are:
-
- Associative containers allow access to their elements via iterators. E.g.,
-find returns an iterator to an element with a given key and
-begin returns an iterator to the first element in the container.
-
-
-
-In general, there are two types of methods: find types, and range types.
- Find-type
-methods return iterators corresponding to elements which have been found in some sense, as
-the container searched for them in order to access them (i.e., via the
-find method) or searched for their location in order to insert them
-(i.e., via the insert method). Range-type methods return iterators
-which can be used to traverse the range of all stored elements, (i.e., via the
-begin and end methods).
-
-
-
Correspondingly, in pb_assoc there are two types of iterators: find type
-iterators are returned by find methods, and range iterators are returned by range methods. For example,
-if T is any associative container with integer keys, and t
-is a container of type T,
-then the following snippet is valid:
-
- In pb_assoc "multimaps" are
-"maps" of "sets". While this design allows efficient
-operations, it makes for cumbersome use at points. For example a
-"multimap" of integers to characters does not
-directly support inser(std::make_pair(2, 'b'), since 2 is mapped
-to a "set" of characters, and not to a character.
-
-
-
- Consequently, pb_assoc contains a rebind-like mechanism so that
-containers can support such operations. To dispel ambiguity, container types are
-assigned mapping levels. "Maps" and "sets" have
-a mapping level 1, since they use a single association level. The "multimap"
-above has a mapping level 2, since it uses two association levels: one for integers, and one for characters. The rebind mechanism can be used to alter the association level. This is described in
-Mapping Semantics.
-
Constructor. max_count determines the the number of times each node is accessed until the count is reset to 0 and the node moved to the front of the list.
-Permission to use, copy, modify, sell, and distribute this software is hereby granted without fee, provided that the above copyright notice appears in all copies, and that both that copyright notice and this permission notice appear in supporting documentation.
-
-
-None of the above authors, nor IBM Haifa Research Laboratories, Red Hat, or both, make any representation about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
-
- The design attempts to address the following problem. When writing a function manipulating a generic container object, what is the behaviour of the object? E.g., suppose one writes
-
-then one needs to address the following questions in the body
-of some_op_sequence:
-
-
Which types and methods does Cntnr support? Containers based on hash tables can be queries for the hash-functor type and object; this is meaningless for tree-based containers. Containers based on trees can be split, joined, or can erase iterators and return the following iterator; this cannot be done by hash-based containers.
-
- What are the guarantees of Cntnr? A container based on a probing hash-table invalidates all iterators when it is modified; this is not the case for containers based on node-based trees. Containers based on a node-based tree can be split or joined without exceptions; this is not the case for containers based on vector-based trees.
-
-
How does the container maintain its elements? containers based on splay trees or lists with update policies "cache" "frequently accessed" elements; containers based on most other underlying data-structures do not.
-cc_hash_assoc_cntnr
-and
-gp_hash_assoc_cntnr
-each subclass
-basic_hash_assoc_cntnr, and encapsulate collision-chaining and (general) probing hash tables, respectively. These two types of hash tables have somewhat different policies and methods (i.e., constructors and policy-access methods).
-
- The hierarchy is composed naturally, such that each container inherits
-all types and methods from its base. Data-Structure Tags and Traits discusses how to query which types and methods each container supports.
-
- basic_assoc_cntnr publicly defines
-ds_category as one of the classes in Figure
-.
-Given any container Cntnr, the tag of the underlying data-structure can be found via typename Cntnr::ds_category.
-
-
-
- Additionally, a traits mechanism can be used to query a container type for its attributes. Given any container Cntnr, then
-ds_traits<Cntnr>
-is a traits class identifying the properties of the container.
-
-
-
- To find if a container can throw when a key is erased (which is true for vector-based trees, for example), one can use
-
- Some of the definitions in
-ds_traits
-are dependent on other definitions. E.g., if
-ds_traits<Cntnr>::split_join
-is true (which is the case for containers based on trees),
-then
-ds_traits<Cntnr>::split_join_can_throw
-indicates whether splits or joins can throw exceptions (which is true for vector-based trees); otherwise
-ds_traits<Cntnr>::split_join_can_throw
-will yield a compilation error. (This is somewhat similar to a compile-time
-version of the COM model
-[mscom]).
-
-
-
- pb_assoc differentiates between two types of methods: find-type methods, and range-type methods. For example, find is a find-type method, since a container object searches for an element with a given key; insert is a find-type method, since, by STL convention, a container object returns an iterator corresponding to an element with a given key; begin and end are range-type methods, since they are not used to find a specific element, but rather to go over all elements in a container object.
-
-
-
- Correspondingly, containers in pb_assoc define two families of iterators. const_find_iterator and find_iterator are the iterator types returned by find-type methods; const_iterator and iterator are the iterator types returned by range-type methods.
-
-
-
- The relationship between these iterator types varies between container types. In a tree-based container, for example, const_find_iterator and const_iterator are synonymous, and find_iterator and iterator are synonymous; in a hash-based container, for example, this is not the case. Futhermore, find-type iterators in a hash-based container lack movement operators, such as
- operator++.
- All containers, however, maintain the invariants shown in Figure
-
-.
-
-
-
-
- This distinction between find-type and range-type iterators and methods, while complicating the interface, has several advantages:
-
-
-
Iterators in unordered container types
-
-
- Given an unordered container type, e.g., a hash-based container, it makes no sense to move an iterator returned by a find-type method.
-Let cntnr be an associative-container object, and
-consider:
-
-
-
-std::for_each(m.find(1), m.find(5), foo);
-
-
-
-which applies foo to all elements in m
-between 1 and 5.
-
-
-
If cntnr is a
-tree-based container object, then an in-order walk will apply foo
-to the relevant elements, e.g., as in Figure
-Range iteration in different data-structures
--A. If m is a
-hash-based container, then the order of elements between any two
-elements is undefined (and probably time-varying); there is no
-guarantee that the elements traversed will coincide with the
-logical elements between 1 and 5, e.g., as in
-Figure Range iteration in different data-structures-B.
-
-
-
-The application of a
-range function e.g., for_each, to a
-pair of hash-based container's iterators is possibly sensical only
-if the iterators are those returned by begin and end,
-respectively. Therefore, the iterator returned by
-m's find method should be immovable.
-
-
-
- Another point also indicates that hash-based containers'
-find-type iterators and range-type iterators should be distinct.
-Consider Figure
-
-Find-type iterators in hash tables-A.
-An
-(immovable) find-type iterator, designed only to access an
-element, requires at most a single pointer to the element's link.
-Conversely, an iterator designed for range operations
-requires some more information e.g., the bucket number),
-since a cross-list traversal might be necessary. Alternatively,
-the lists might be linked, forming a monolithic total-element
-list, as in Figure
-
-Find-type iterators in hash tables-B (this seems
-similar to the Dinkumware design
-[dinkumware_stl]). This,
-however, complicates the hash-table's operations.
-
-
- will compile for tree-based containers, but will not compile
-for hash-tables or other types. The returned type of find
-is a find-type iterator. For tree-based containers, this is synonymous
-with a range-type iterator, and therefore supports operator++;
-for other types of containers, a find-type iterator lacks operator++.
-
-
-
Invalidation Guarantees
-
-
- Consider the following snippet:
-
-
-
-it = c.find(3);
-
-c.erase(5);
-
-
-
- Following the call to erase, what is the validity
-of it: can it be dereferenced? can it be incremented?
-
-
-
- The answer depends on the underlying data-structure of the container.
-Figure
-Effect of erase in different underlying data-structures
-shows three cases: A1 and A2 show a red-black tree;
-B1 and B2 show an ordered-vector tree; C1 and C2
-show a collision-chaining hash table.
-
-Effect of erase in different underlying data-structures.
-
-
-
-
-
- `Erasing 5 from A1 yields A2. Clearly, an iterator to 3
- can be dereferenced and incremented.
-
-
- Erasing 5 from B1 yields B2. Clearly, an iterator to 3 is
- not valid at all.
-
-
- Erasing 5 from C1 yields C2. Here the situation is more complicated.
-On the one hand, incrementing it can be undefined. On the other
-hand, there is no problem in dereferencing it. In
-classic STL, it is not possible to express whether it
-is valid or not.
-
-
-
-
- Thus again, the iterator concept seems overloaded. Distinguishing
-between find and range types allows fine-grained invalidation guarantees.
-Invalidation guarantees class hierarchy
-shows tags corresponding to different types of invalidation guarantees.
-
basic_invalidation_guarantee corresponds to a basic guarantee that a find-type iterator, a found pointer, or a found reference, remains valid as long as the container object is not modified.
-
-
find_invalidation_guarantee corresponds to a guarantee that a find-type iterator, a found pointer, or a found reference, remains valid even if the containter object is modified.
-
-
range_invalidation_guarantee corresponds to a guarantee that a range-type iterator remains valid even if the containter object is modified.
-
-
-
-
-
- To find the invalidation guarantee of a container, one can use
-
Signifies a basic invalidation guarantee that any iterator, pointer, or reference to a container object's mapped value type is valid as long as the container is not modified.
-
No resources are leaked in the face of exceptions. In particular, this means:
-
-
By the time a container's destructor completes:
-
-
It has returned all memory it has allocated to the appropriate deallocation function.
-
The destructor has been called for all objects constructed by the container.
-
-
Algorithms destroy all temporary objects and deallocate all temporary memory even if the algorithm does not complete due to an exception.
-
Algorithms which construct objects either complete successfully or destroy any objects they have constructed at the time of the exception.
-
Algorithms which destruct objects always succeed.
-
Containers continue to fulfill all of their requirements, even after an exception occurs during a mutating function. For example, they will never give an inaccurate report of its size, or fail to meet performance requirements because of some thrown exception.
-
-
-
Thestrong guarantee: If an operation on a container fails due to an exception, then, semantically, the operation is a no-op applied to the container.
Signifies an invalidation guarantee that includes all those of its base, and additionally, that any find-type iterator, pointer, or reference to a container object's mapped value type is valid as long as its corresponding entry has not be erased, regardless of modifications to the container object.
-
- Naturally, the ability to program generically different associative containers, is beneficial.
-The distinction in this library between data_types and
-mapped_data_types, and between value_types and
-mapped_value_types, somewhat complicates this.
-
-
-
- The generic utility classes ease static detection of different associative-container
-types (e.g., whether they are map or multimap types), and the extraction of data from iterators.
-
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, and r_eq_fn will be copied by the Eq_Fn object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, and r_comb_probe_fn will be copied by the Comb_Probe_Fn object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, r_comb_probe_fn will be copied by the Comb_Probe_Fn object of the container object, and r_probe_fn will be copied by the Probe_Fn object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, r_comb_probe_fn will be copied by the Comb_Probe_Fn object of the container object, r_probe_fn will be copied by the Probe_Fn object of the container object, and r_resize_policy will be copied by the Resize_Policy object of the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- gp_hash_assoc_cntnr
- (It first_it,
- It last_it)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types. The value_types between first_it and last_it will be inserted into the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- gp_hash_assoc_cntnr
- (It first_it,
- It last_it,
- constHash_Fn &r_hash_fn)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- gp_hash_assoc_cntnr
- (It first_it,
- It last_it,
- constHash_Fn &r_hash_fn,
- constEq_Fn &r_eq_fn)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, and r_eq_fn will be copied by the Eq_Fn object of the container object.
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, and r_comb_probe_fn will be copied by the Comb_Probe_Fn object of the container object.
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, r_comb_probe_fn will be copied by the Comb_Probe_Fn object of the container object, and r_probe_fn will be copied by the Probe_Fn object of the container object.
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object. r_hash_fn will be copied by the Hash_Fn object of the container object, r_eq_fn will be copied by the Eq_Fn object of the container object, r_comb_probe_fn will be copied by the Comb_Probe_Fn object of the container object, r_probe_fn will be copied by the Probe_Fn object of the container object, and r_resize_policy will be copied by the Resize_Policy object of the container object.
- As mentioned in
-Hash Policies,
-some of the containers require a ranged-hash function policy for
-mapping key types into a non-negative integral type in a range.
-E.g., collision-based containers
-(cc_ht_map,
-cc_ht_set,
-cc_ht_multimap,
-and
-cc_ht_multiset),
-require a ranged-hash function.
-
-
-
- Similarly, some hash tables
-need a ranged-probe function policy for mapping
-key types into a sequence of non-negative integral types in a range.
-E.g., probing-based containers
-(gp_ht_map,
-gp_ht_set,
-gp_ht_multimap,
-and
-gp_ht_multiset),
-require a ranged-hash function.
-
-
-
- Policy Classes
-contains classes for creating ranged-hash and ranged-probe function policies.
-
Comb_Hash_Fn is a range-hashing_functor; it
-describes how to translate hash values into positions within the table.
-This is described in
-Hash Policies.
-
-
Resize_Policy describes how a container object should
-change its internal size. This is described in
-Resize Policies.
-
Store_Hash indicates whether the hash value should
-be stored with each entry. This is described in
-Policy Interaction.
-
Allocator is (surprisingly) an allocator type.
-
-
-
-
- The probing hash-based container has the following declaration.
-
-
-template<
- typename Key,
- typename Data,
- class Hash_Fn =
- std::hash<
- Key>,
- class Eq_Fn =
- std::equal_to<
- Key>,
- class Comb_Probe_Fn =
- direct_mask_range_hashing<>
- class Probe_Fn = default explained below.
- class Resize_Policy = default explained below.
- bool Store_Hash = false,
- class Allocator =
- std::allocator<char> >
-classgp_hash_assoc_cntnr;
-
-
-
- The parameters are identical to those of the collision-chaining container, except
-for the following.
-
-
-
Comb_Probe_Fn describes how to transform a probe sequence into
-a sequence of positions within the table.
-
-
Probe_Fn describes a probe sequence policy.
-
-
-
-
- Some of the default template values depend on the values of other parameters,
-and are explained in
-Policy Interaction.
-
- A ranged-hash function, which maps keys into an interval of the
- non-negative integrals. This is the function actually required by the
- hash-table algorithm.
-
-
- A hash function, which maps keys into non-negative integral types. This is
- typically specified by the writer of the key class.
-
-
- A range-hashing function, which maps non-negative integral types into an
- interval of non-negative integral types.
-
-
-Hash runctions, ranged-hash functions, and range-hashing functions.
-
-
-
- Let U be a domain (e.g., the integers, or the strings of 3
- characters). A hash-table algorithm needs to map elements of U "uniformly"
- into the range [0,..., m - 1] (where m is a non-negative integral
- value, and is, in general, time varying). I.e., the algorithm needs a ranged-hash
- function
-
-
- f : U × Z+ → Z+,
-
-
- such that for any u in U
-,
-
-
- 0 ≤ f(u, m) ≤ m - 1 ,
-
-
- and which has "good uniformity" properties [knuth98sorting].
- One common solution is to use the composition of the hash function
-
-
- h : U → Z+,
-
-
- which maps elements of U into the non-negative integrals, and
-
-
- g : Z+ × Z+ → Z+,
-
-
- which maps a non-negative hash value, and a non-negative range upper-bound into
- a non-negative integral in the range between 0 (inclusive) and the range upper
- bound (exclusive), i.e., for any r in Z+,
-
- From the above, it is obvious that given g and h, f can
- always be composed (however the converse is not true). The STL's hash-based
- containers allow specifying a hash function, and use a hard-wired range-hashing function; the ranged-hash function is implicitly composed.
-
-
-
-
- The above describes the case where a key is to be mapped into a single
-position within a hash table, e.g., in a collision-chaining table.
-In other cases, a key is to be mapped into a sequence of poisitions
-within a table, e.g., in a probing table.
-
-
- Similar terms apply in this case: the table requires a ranged probe
-function, mapping a key into a sequence of positions withing the table. This is
-typically acheived by composing a hash function mapping the key
-into a non-negative integral type, a probe function transforming the
-hash value into a sequence of hash values, and a range-hashing function
-transforming the sequence of hash values into a sequence of positions.
-
-respectively, for some positive integrals u and v (typically
-powers of 2), and some a. Each of these range-hashing functions works
-best for some different setting.
-
-
- The division method (2) is a very common
- choice. However, even this single method can be implemented in two very
- different ways. It is possible to implement (2)
- using the low level % (modulo) operation (for any m), or the low
- level & (bit-mask) operation (for the case where m is a power of
- 2), i.e.,
-
- The % (modulo) implementation (3)
- has the advantage that for m a prime far from a power of 2, g(r, m)
- is affected by all the bits of r (minimizing the chance of collision).
- It has the disadvantage of using the costly modulo operation. This method is
- hard-wired into SGI's implementation [sgi_stl].
-
-
-
- The & (bit-mask) implementation (4)
- has the advantage of relying on the fast bitwise and operation. It has the
- disadvantage that for g(r, m) is affected only by the low order bits of r.
- This method is hard-wired into Dinkumware's implementation [dinkumware_stl].
-
- In some less frequent cases it is beneficial to allow the client to
-directly specify a ranged-hash hash function. It is true, that the writer of
-the ranged-hash function cannot rely on the values of m having specific
-numerical properties suitable for hashing (in the sense used in [knuth98sorting]),
-since the values of m are determined by a resize policy with possibly
-orthogonal considerations.
-
-
-
- There are two cases where a ranged-hash function can be superior. The firs is when using perfect hashing
-[knuth98sorting]; the second
-is when the values of m can be used to estimate the
-"general" number of distinct values required. This is described in the following.
-
-
-
- Let
-
-
-
- s = [ s0,..., st - 1]
-
-
-
- be a string of t characters, each of which is from domain S.
-Consider the following ranged-hash function:
-
- where a is some non-negative integral value. This is the standard
-string-hashing function used in SGI's implementation (with a = 5) [sgi_stl].
-Its advantage is that it takes into account all of the characters of the
-string.
-
-
-
- Now assume that s is the string representation of a of a long DNA
-sequence (and so S = {'A', 'C', 'G', 'T'}). In this case, scanning the
-entire string might be prohibitively expensive. A possible alternative might be
-to use only the first k characters of the string, where
-
- Other more elaborate hash-functions might scan k characters starting at
- a random position (determined at each resize), or scanning k random
- positions (determined at each resize), i.e., using
-
-
- f3(s, m) = ∑ i = r0r0 + k - 1
- si aimod m ,
-
-
- or
-
-
- f4(s, m) = ∑ i = 0k - 1 sri
- arimod m ,
-
-
-
- respectively, for r0,..., rk-1 each in the
- (inclusive) range [0,...,t-1].
-
-cc_hash_assoc_cntnr is
-parameterized by Hash_Fn and Comb_Hash_Fn, a hash functor
-and a combining hash functor, respectively.
-
-
-
- For any hash functor except null_hash_fn,
-one of the
-Concepts::Null Policy Classes,
-then Comb_Hash_Fn is considered a range-hashing functor.
-The container will synthesize a ranged-hash functor from both. For example, Figure
-
-Insert hash sequence diagram
-
-shows an insert sequence diagram. The user inserts an element (point A),
-the container transforms the key into a non-negative integral using the hash
-functor (points B and C), and transforms the result into a position
-using the combining functor (points D and E).
-
- If Comb_Hash_Fn is instantiated by
-null_hash_fn,
-and a combining-hash functor, the container treats
-the combining hash functor as a ranged-hash function. For example, Figure
-
-Insert hash sequence diagram with a null combination policy
-
-shows an insert sequence diagram. The user inserts an element (point A),
-the container transforms the key into a position
-using the combining functor (points B and C).
-
-Insert hash sequence diagram with a null combination policy.
-
-
-
- Similarly,
-gp_hash_assoc_cntnr
-is parameterized by Hash_Fn, Probe_Fn, and
-Comb_Probe_Fn. As before, if Probe_Fn
-and Comb_Probe_Fn are, respectively,
-null_hash_fn and
-null_probe_fn,
-then Comb_Probe_Fn is a ranged-probe functor. Otherwise, Hash_Fn
-is a hash functor, Probe_Fn is a functor for offsets from a hash value,
-and Comb_Probe_Fn transforms a probe sequence into a sequence of positions
-within the table.
-
-
-
- pb_assoc contains the following probe policies:
-
- Hash-tables, as opposed to trees, do not naturally grow or shrink. It
-is necessary to specify policies to determine how and when a hash table should change
-its size.
-
-
-
- In general, resize policies can be decomposed into (probably orthogonal)
-policies:
-
-
-
A size policy indicating how a hash table should
-grow (e.g., it should multiply by powers of 2).
-
-
A trigger policy indicating when a hash table should
-grow (e.g., a load factor is exceeded).
-
- Size policies determine how a hash table
-changes size. These policies are simple, and there are relatively
-few sensible options. An exponential-size policy (with the initial
-size and growth factors both powers of 2) works well with a
-mask-based range-hashing function (see the Range-Hashing Policies subsection),
-and is the
-hard-wired policy used by Dinkumware
-[dinkumware_stl]. A
-prime-list based policy works well with a modulo-prime range
-hashing function (see the Range-Hashing Policies subsection),
-and is the
-hard-wired policy used by SGI's implementation
-[sgi_stl].
-
- Trigger policies determine when a hash table changes size.
-Following is a description of two polcies: load-check
-policies, and a collision-check policies.
-
-
-
- Load-check policies are straightforward. The user
-specifies two factors, αmin and αmax, and
-the hash table maintains the invariant that
-
- Collision-check policies work in the opposite direction of
-load-check policies. They focus on keeping the number of
-collisions moderate and hoping
-that the size of the table will not grow very large,
-instead of keeping a moderate load-factor and
-hoping that the number of collisions will be small.
-A
-maximal collision-check policy resizes when the shortest
-probe-sequence grows too large.
-
-
-
-
- Consider Figure
-Balls and bins.
- Let the size of the hash table be denoted by m, the
-length of a probe sequence be denoted by k, and some load
-factor be denoted by α. We would like to calculate the
-minimal length of k, such that if there were α m elements
-in the hash table, a probe sequence of length k would be found
-with probability at most 1/m.
-
- Denote the probability that a probe sequence of length k
-appears in bin i by pi, the length of the probe sequence
-of bin i by li, and assume uniform distribution.
-Then
-
- where (a) follows from the Chernoff bound
-[motwani95random].
-To
-calculate the probability that some bin contains a probe
-sequence greater than k, we note that the li are
-negatively-dependent
-[dubhashi98neg].
-Let I(.)
-denote the indicator function. Then
-
-where (a) follows from the fact that the Chernoff bound can be
-applied to negatively-dependent variables
-[dubhashi98neg].
-Inserting (2) into
-(3), and equating with 1/m,
-we obtain
-
- The resize policies in the previous subsection are conceptually straightforward. The design
-of hash-based containers' size-related interface is complicated by some factors.
-
-
-
Most containers, i.e. lists, trees, and vectors, have a single "size" concept. There is no
-distinction between the number of entries the container holds and the number of entries it is using. This,
-of course, is not the case for hash-based containers. Moreover, even describing the
-"actual" size of a hash-based container (as opposed to its logical size) is difficult - a probing-based container
-holds entries to elements, even those it does not use, while a chaining-based container holds pointers to entries.
-
-
- The policies mentioned above operate in terms of invariants. E.g. a load-check trigger policy
-maintains an invariant concerning the load factor of a container object. This is sometimes too rigid:
-
-
In some cases it is desirable to allow controlled override of an entire policy, e.g. by externally resizing a container object (or giving it an initial size, which is a special case of externally resizing the container).
-
-
- In other cases it is desirable to allow changing the specifics of a policy in runtime, e.g., changing the load factors of a load-check policy.
-
-
-
-
- Resize policies interact strongly with hash policies. Performance-wise, for example, it is undesirable to use an exponential size policy of powers of two with a modulo range-hashing function, and it is undesirable to use a prime size policy with a mask range-hashing function. In other cases, the effects are more dramatic. For example, using a quadratic probe function with an exponential size policy will probably cause cases where the container object has available entries which are never reached by the probe function. (Hash Policies
-discusses the previous concepts.)
-
-
-
-
- Clearly, the more of these points an interface addresses, the greater its flexibility but the lower its encapsulation and uniformity between associative containers.
-
-
-
-
-
- This library attempts to address these types of problems by delegating all size-related functionality to
-policy classes. Hash-based containers
-are parameterized by a resize-policy class (among others), and derive publicly from
-the resize-policy class
-[alexandrescu01modern]
- E.g., a collision-chaining
-hash table is defined as follows:
-
-
-cc_ht_map<
- class Key,
- class Data,
- ...
- class Resize_Policy
- ...> :
- public Resize_Policy
-
-
-
- The containers themselves lack any functionality or public interface for manipulating sizes. A container
-object merely forwards events to its resize policy object and queries it for needed actions.
-
-
-
- Figure
-
-Insert resize sequence diagram
-
-shows a (possible) sequence diagram of an insert operation.
-The user inserts an element; the hash table
-notifies its resize policy that a search has started (point A);
-in this case, a single collision is encountered - the table
-notifies its resize policy of this (point B); the container
-finally notifies its resize policy that the search has ended (point C);
-it then queries its resize policy whether a resize is needed, and if so,
-what is the new size (points D to G); following the resize, it notifies
-the policy that a resize has completed (point H); finally, the element
-is inserted, and the policy notified (point I).
-
- This addresses, to some extent, the problems mentioned above:
-
-
-
- Different instantiations of range-hashing policies can be met with different instantiations of
- resize policies.
-
-
- Questions on size-related interface are avoided, since the containers have no size-related methods. Thus
- a container has no method for querying its actual size. It merely continuously forwards enough information to
- its resize policy to answer such queries; the designer of the resize policy can decide whether, or how, to design the appropriate method. Also, a container has no methods for setting its size. It merely queries its
-resize policy for an initial size, queries it on a new size (if the resize policy indicates a resize is needed), and
-supports a protected virtual function for external resize.
-
-
-
-
- The library contains a single class for instantiating a resize policy,
-pb_assoc contains
-a standard resize policy,
-hash_standard_resize_policy (the name is explained shortly).
-In terms of interface, it is parameterized by a boolean constant indicating whether its public interface supports
-queries of actual size and external resize operations (the inclusion and exclusion of these methods in the interface have obvious tradeoffs in terms of encapsulation and flexibility).
-([alexandrescu01modern] shows many techniques for
-changing between alternative interfaces at compile time.)
-
-
-
-As noted before,
- size and trigger policies are usually orthogonal.
-hash_standard_resize_policy
-is parameterized by size and trigger policies. For example,
-a collision-chaining hash table
-is typically be defined as follows:
-
- Hash-tables are unfortunately susceptible to choice of policies. One
-of the more complicated aspects of this is that poor combinations of good policies
-can alter performance drastically. Following are some considerations.
-
-
-
-
-
-
-
Range-Hashing Policies and Resize Policies
-
-
-
-
-
-
Equivalence Functors, Storing Hash Values, and Hash Functions
-
-
-
-cc_hash_assoc_cntnr
-and
-gp_hash_assoc_cntnr
-are parameterized by an equivalenc functor and by a Store_Hash
-parameter. If the latter parameter is true, then
-the container stores with each entry a hash value, and uses
-this value in case of collisions to determine whether to apply a hash value.
-This can lower the cost of collision for some types, but increase the cost of collisions for other types.
-
-
-
- If a ranged-hash function or ranged probe function is directly supplied, however,
-then it makes no sense to store the hash value with each entry. pb_assoc's container will fail at compilation, by design, if this is attempted.
-
Default constructor, or onstructor taking a start_size, a start size and grow_factor, a growth factor. The policy will use the sequence of sizes start_size, start_size * grow_factor, start_size * grow_factor^2, ...
-A hash function is essentially an std::unary_operator. It takes a
-const_key_reference, and returns
-a (non-negative) integral type.
-
-
-
- A special hash function, null_hash_fn
-serves to indicate that the ranged-hash function
-or ranged-probe function should not be formed by composition.
-
Specifies whether the load factor can be accessed externally. The two options have different tradeoffs in terms of flexibility, genericity, and encapsulation.
Sets the loads through a pair of the minimal and maximal loads, respectively.
-
-
-
Calling this method resizes the container, and might throw an exception. It is the responsibility of the user to pass appropriate loads to this function. Calling this method will not compile when External_Load_Access == false.
This method is called only if this object indicated resize is needed. The actual size of the table is size, and the number of entries in it is num_entries.
This method is called only if this object indicated resize is needed. The actual size of the table is size, and the number of entries in it is num_entries.
- A ranged-hash function, which maps keys into an interval of the
- non-negative integrals. This is the function actually required by the
- hash-table algorithm.
-
-
- A hash function, which maps keys into non-negative integral types. This is
- typically specified by the writer of the key class.
-
-
- A range-hashing function, which maps non-negative integral types into an
- interval of non-negative integral types.
-
- Let U be a domain (e.g., the integers, or the strings of 3
- characters). A hash-table algorithm needs to map elements of U "uniformly"
- into the range [0,..., m - 1] (where m is a non-negative integral
- value, and is, in general, time varying). I.e., the algorithm needs a ranged-hash
- function
-
-
- f : U × Z+ → Z+,
-
-
- such that for any u in U
-,
-
-
- 0 ≤ f(u, m) ≤ m - 1 ,
-
-
- and which has "good uniformity" properties [knuth98sorting].
- One common solution is to use the composition of the hash function
-
-
- h : U → Z+,
-
-
- which maps elements of U into the non-negative integrals, and
-
-
- g : Z+ × Z+ → Z+,
-
-
- which maps a non-negative hash value, and a non-negative range upper-bound into
- a non-negative integral in the range between 0 (inclusive) and the range upper
- bound (exclusive), i.e., for any r in Z+,
-
- From the above, it is obvious that given g and h, f can
- always be composed (however the converse is not true).
-
-
-
-
- The above describes the case where a key is to be mapped into a single
-position within a hash table, e.g., in a collision-chaining table.
-In other cases, a key is to be mapped into a sequence of poisitions
-within a table, e.g., in a probing table.
-
-
- Similar terms apply in this case: the table requires a ranged probe
-function, mapping a key into a sequence of positions withing the table. This is
-typically acheived by composing a hash function mapping the key
-into a non-negative integral type, a probe function transforming the
-hash value into a sequence of hash values, and a range-hashing function
-transforming the sequence of hash values into a sequence of positions.
-
-respectively, for some positive integrals u and v (typically
-powers of 2), and some a. Each of these range-hashing functions works
-best for some different setting.
-
-
- The division method (2) is a very common
- choice. However, even this single method can be implemented in two very
- different ways. It is possible to implement (2)
- using the low level % (modulo) operation (for any m), or the low
- level & (bit-mask) operation (for the case where m is a power of
- 2), i.e.,
-
- The % (modulo) implementation (3)
- has the advantage that for m a prime far from a power of 2, g(r, m)
- is affected by all the bits of r (minimizing the chance of collision).
- It has the disadvantage of using the costly modulo operation. This method is
- hard-wired into SGI's implementation [sgi_stl].
-
-
-
- The & (bit-mask) implementation (4)
- has the advantage of relying on the fast bitwise and operation. It has the
- disadvantage that for g(r, m) is affected only by the low order bits of r.
- This method is hard-wired into Dinkumware's implementation [dinkumware_stl].
-
- Although rarer, there are cases where it is beneficial to allow the client to
-directly specify a ranged-hash hash function. It is true, that the writer of
-the ranged-hash function cannot rely on the values of m having specific
-numerical properties suitable for hashing (in the sense used in [knuth98sorting]),
-since the values of m are determined by a resize policy with possibly
-orthogonal considerations [austern98segmented].
-The values of m can be used in some cases, though, to estimate the
-"general" number of distinct values required.
-
-
-
- Let
-
-
-
- s = [ s0,..., st - 1]
-
-
-
- be a string of t characters, each of which is from domain S.
-Consider the following ranged-hash function:
-
- where a is some non-negative integral value. This is the standard
-string-hashing function used in SGI's implementation (with a = 5) [sgi_stl].
-Its advantage is that it takes into account all of the characters of the
-string.
-
-
-
- Now assume that s is the string representation of a of a long DNA
-sequence (and so S = {'A', 'C', 'G', 'T'}). In this case, scanning the
-entire string might be prohibitively expensive. A possible alternative might be
-to use only the first k characters of the string, where
-
- Other more elaborate hash-functions might scan k characters starting at
- a random position (determined at each resize), or scanning k random
- positions (determined at each resize), i.e., using
-
-
- f3(s, m) = ∑ i = r0r0 + k - 1
- si aimod m ,
-
-
- or
-
-
- f4(s, m) = ∑ i = 0k - 1 sri
- arimod m ,
-
-
-
- respectively, for r0,..., rk-1 each in the
- (inclusive) range [0,...,t-1].
-
- Containers based on collision-chaining hash tables in pb_assoc
-are parameterized by the functors Hash_Fn, and Comb_Hash_Fn.
-
-
-
- If such a container is instantiated with any hash functor and
-range-hashing functor, the container will synthesize a ranged-hash functor
-automatically. For example, Figure
-
-Insert hash sequence diagram
-
-shows an insert sequence diagram. The user inserts an element (point A),
-the container transforms the key into a non-negative integral using the hash
-functor (points B and C), and transforms the result into a position
-using the combining functor (points D and E).
-
- If such a container is instantiated with the
-null policy
-hash functor,
-null_hash_fn,
-and a combining-hash functor, the container treats
-the combining hash functor as a ranged-hash function. For example, Figure
-
-Insert hash sequence diagram with a null combination policy
-
-shows an insert sequence diagram. The user inserts an element (point A),
-the container transforms the key into a position
-using the combining functor (points B and C).
-
constructor taking some policies and suggested_size, a suggested size (the actual size will be determined by the Size_Policy object). r_size_policy will be copied by the Size_Policy object of this object.
constructor taking some policies and suggested_size, a suggested size (the actual size will be determined by the Size_Policy object). r_size_policy will be copied by the Size_Policy object of this object. r_trigger_policy will be copied by the Trigger_Policy object of this object.
This method returns the number of entries (used and unused) in the container. It is different from the container's size method, which returns the number of used entries. Calling this method will not compile when External_Size_Access == false.
-[1] Note that for multimap types, the mapped data part is a collection, and so the average and worst case complexities
-need to be multiplied by the corresponding complexities of copying collections.
-
- There are (at least) three orthogonal challenges to designing generic associative containers:
-
-
-
-
The choice of underlying data-structure affects not only the performance of containers, but their semantics as well. E.g., containers based on trees store elements by a given order, while containers based on hash tables store elements in a meaningless (and probably time-varying) order; containers based on node-based trees can guarantee exception-free element erasing, while containers based on vector-based trees cannot. This complicates generic manipulation of associative containers based on different underlying data-structures.
-
-
- Underlying data-structures can act very differently given different policies. E.g., the policy by which a hash table translates a hash value into a position within a table affects performance dramatically; certain policies can make containers based on trees support order statistics (i.e., queries on the order of stored elements) or other useful queries. This complicates the policy design of an associative container based on a given data-structure.
-
-
- Various mapping semantics are appropriate in different settings. E.g., in some cases a unique mapping between each key and a datum is appropriate (such as the STL's std::map guarantees); in other cases, unique storage of keys is required (such as the STL's std::set guarantees); in other cases, more complex mapping semantics are required. This complicates generic manipulation of associative containers with different mapping semantics.
-
-
-
-
- pb_assoc attempts to address these problems safely and efficiently.
-
- The library compiles and runs on the newer versions of
-g++, icc and Visual C++ .net. The
-Portability Section describes the known
-compilers with which it works.
-
-
-
- Unfortunately, we do not have access to other compilers, and so do not
-know how to define some standard policies whose namespaces and declarations
-we know only on
-g++, icc, and Visual C++ .net.
-We would appreciate help on this point.
-
- Associative containers use some attributes of the keys of which they store: tree-based
-containers use the ability to compare keys; hash-based containers use the ability to map
-keys into numbers.
-
-
-
- In the (rare) case where keys can only be checked for equivalence, these
-types of containers cannot be used. In such a case, storing the entries in a list is a reasonable solution.
-Clearly, the order of the elements within the list affects performance; ideally, frequently accessed elements
-should be at the front of the list.
-
-
-
- Many remarkable (online competitive
-[motwani95random])
-algorithms exist for reordering lists to reflect access prediction
-[andrew04mtf]. Some of these algorithms require storing
-metadata with each key, while others do not. Some of these algorithms require only the ability to
-move an element to the front of the list, while others require the ability to interchange an element and
-its predecessor.
-
-
-
- For example, Figure
--A
-The counter algorithm
-
-shows the counter algorithm. Each node contains both a key and a count metadata (shown in bold).
-When an element is accessed (e.g. 6)
-its count is incremented, as shown in
-Figure
-
-The counter algorithm
--B.
-If the count reaches some predetermined value, say 10, as shown in
-Figure
-
-The counter algorithm
--C,
-the count is set to 0
-and the node is moved to the front of the list, as in
-Figure
-
-The counter algorithm
--D.
-
-
-
- The pb_assoc library allows instantiating lists with policies
-implementing any algorithm moving nodes to the front of the list (policies implementing
-algorithms interchanging nodes are currently unsupported).
-
-
-
- Associative containers based on lists are parameterized by a Update_Policy parameter.
-This parameter defines the type of metadata each node contains, how to create the metadata, and how to
-decide, using this metadata, whether to move a node to the front of the list.
- A list-based associative container object derives (publicly) from its update policy.
-
-
-
- An instantiation of Update_Policy must define internally update_metadata as the metadata
-it requires. Internally, each node of the list contains, besides the usual key and data, an instance
-of typename Update_Policy::update_metadata.
-
-
-
- An instantiation of Update_Policy must define internally two operators:
-
- The first is called by the container object, when creating a new node, to create the node's metadata. The
-second is called by the container object, when a node is accessed (e.g., when a find operation's key
-is equivalent to the key of the node), to determine whether to move the node to the front of the list.
-
-
-
- Additionally, the library contains implementations of the move-to-front and counter policies. These
-are described in
-Policy Classes.
-
Constructor taking some policy objects. r_eq_fn will be copied by the Eq_Fn object of the container object, and r_update_policy will be copied by the Update_Policy object of the container object.
-
-
-
-
-
-
-
-
-
template<class It>
- lu_assoc_cntnr
- (It first_it, It last_it)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types. The value_types between first_it and last_it will be inserted into the container object.
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object.
Constructor taking iterators to a range of value_types and some policy objects. The value_types between first_it and last_it will be inserted into the container object.
- Associative containers typically use some attributes of the keys of which they store: tree-based
-containers use the ability to compare keys; hash-based containers use the ability to map
-keys into numbers.
-
-
-
- In some cases it is better to avoid this:
-
-
-
-
- Hash-based and tree-based containers typically require additional memory
- for time efficiency.
-
-
- Hash-based and tree-based containers require extra information
- about keys: hash-based containers need hash functors, tree-based containers need
- comparison functors. In some (rare) cases, a key might be encapsulated to the extent that it is not possible to supply these functors.
-
-
-
-
- In such cases, storing the entries in a unique-key list is a reasonable solution.
-This uses the minimal amount of memory, and requires only an equivalence functor.
-Clearly, the order of the elements within the list affects performance; ideally, frequently accessed elements
-should be at the front of the list.
-
-
-
- Many remarkable (online competitive
-[motwani95random])
-algorithms exist for reordering lists to reflect access prediction
-[andrew04mtf].
-
-
-
- Figure
-List-update containers
- shows the container-hierarchy; the list-based container is circled.
-
- For example, Figure
--A
-The counter algorithm
-
-shows the counter algorithm. Each node contains both a key and a count metadata (shown in bold).
-When an element is accessed (e.g. 6)
-its count is incremented, as shown in
-Figure
-
-The counter algorithm
--B.
-If the count reaches some predetermined value, say 10, as shown in
-Figure
-
-The counter algorithm
--C,
-the count is set to 0
-and the node is moved to the front of the list, as in
-Figure
-
-The counter algorithm
--D.
-
-
-
- The pb_assoc library allows instantiating lists with policies
-implementing any algorithm moving nodes to the front of the list (policies implementing
-algorithms interchanging nodes are currently unsupported).
-
-
-
- Associative containers based on lists are parameterized by a Update_Policy parameter.
-This parameter defines the type of metadata each node contains, how to create the metadata, and how to
-decide, using this metadata, whether to move a node to the front of the list.
- A list-based associative container object derives (publicly) from its update policy.
-
-
-
- An instantiation of Update_Policy must define internally update_metadata as the metadata
-it requires. Internally, each node of the list contains, besides the usual key and data, an instance
-of typename Update_Policy::update_metadata.
-
-
-
- An instantiation of Update_Policy must define internally two operators:
-
- The first is called by the container object, when creating a new node, to create the node's metadata. The
-second is called by the container object, when a node is accessed (e.g., when a find operation's key
-is equivalent to the key of the node), to determine whether to move the node to the front of the list.
-
-
-
- Additionally, the library contains implementations of the move-to-front and counter policies. These
-are described in
-Policy Classes.
-
- In pb_assoc, associative containers have a unique-key design.
-Multimaps, consequently are maps of sets, e.g.,
-a cc_ht_multimap<int, char>
-object maps ints to sets of chars.
- It is often convenient to perform
-value-type operations on multimaps, e.g., in this case, to find a specific
-std::pair<int, char> object (say, std::make_pair(2, 'b'))
-in a multimap object. These types of operations involve typically two steps: in the
-first step, some operation is performed on the multimap object itself, and in the second
-step, some operation is performed on the multimap's pertinent set object.
-(This is true for the STL's multimaps as well, except that the "set" is an implicit
-list.)
-
-
-
- Coding these two-step operations is repetitious and error prone.
- pb_assoc containers already maintain the invariant that they support
-a value-type method for any mapped-value-type method they support
-(hence any multimap of the above type supporsts a method for inserting
- std::make_pair(2, 'b')). Following are some utility functions for
- other common operations.
-
- Finds the (const reference to a) value-type
-r_val in
-the multimap object
-r_mmap_cntnr.
-
-
- It
-returns a pair whose first entry is a find-type iterator
-of the multimap's set type, and whose second entry is a boolean
-indicating whether the value type was found (only in this
-case is the first entry in the pair valid).
-
- Transactionally erases the (const reference to the) value-type
-r_val from
-the multimap object
-r_mmap_cntnr, and
-erases the mapped value type
-with
-r_val's key
-if there are no more value types with this given key
-and
-erase_entry_if_last= true.
-
-
- It
-returns 1 if a value type was actually erased, or 0 otherwise.
-
-
-
- Transactionally erases
-r_val
-from
-r_mmap_cntnr
-(if it such a value type exists) and
-inserts instead a value type whose key is
-r_val.first
-and whose data is
-r_data.
-
-
-
- It
-returns a pair whose first entry is a find-type iterator
-of the multimap's set type, and whose second entry is a boolean
-indicating whether the new value type was inserted
-(it might have
-existed previously).
-
-
-
-(If the multimap type or its set type do not guarantee exception free
-erases, mmap_value_erase and mmap_value_replace will
-invalidate pointers, references, and iterators).
-
- The Introduction Section described some challenges
-in designing associative containers. This section describes the STL's solution and motivation for an alternative solution. It is organized as follows.
-
- The STL (or its extensions) currently offer associative containers based on underlying red-black trees or collision-chaining hash tables. For association, containers based on trees are parameterized by a comparison functor, and containers based on hash tables are parameterized by a hash functor and an equivalence functor.
-
-
-
- For each underlying data-structure, the STL offers four containers with different mapping semantics. A map-type uniquely maps each key to some datum, a set-type stores uniquely keys, a multimap-type non-uniquely maps each key to some datum, and a multiset-type non-uniquely stores keys.
-
-
-
- Containers contain various iterator-based methods. E.g., all containers have constructors taking a pair of iterators, and transactionally construct an object containing all elements in the iterators' range. Additionally, it is possible to (non-transactionally) insert a range given by iterators, or erase such a range. Other methods are implicitly range-based, e.g., it is possible to test the equivalence of two associative container objects via operator==.
-
- In order to function efficiently in various settings, associative containers require
-a wide variety of policies.
-
-
-
- For example, a hash policy instructs how to transform a key object into some non-negative integral type; e.g., a hash functor might transform "hello" into 1123002298. A hash table, though, requires transforming each key object into some non-negative integral type in some specific domain; e.g., a hash table with 128 entries might transform the "hello" into position 63. The policy by which the hash value is transformed into a position within the table can dramatically affect performance.
-
-
-
- Additionally, most hash-table algorithms encounter collisions. To mitigate the cost of these collisions, it sometimes is beneficial to store the hash value along with each element
-[clrs2001, austern01htprop]. While this improves performance for complex keys, it hampers performance for simple keys, and is best left as a policy.
-
-
-
- Tree-based containers allow reasonable access while maintaining order between elements. In some cases, however, tree-based containers can be used for additional purposes. E.g.,consider Figure
-
-Sets of line intervals
--A,
-which shows
-an example of a tree-based set storing
-half-open geometric line intervals. An std::set with this
-structure can efficiently answer whether [20, 101) is in the
-set, but it cannot efficiently answer whether any interval in the
-set overlaps [20, 101), nor can it efficiently enumerate all
-intervals overlapping [20, 101). A well-known augmentation to
-balanced trees can support efficient answers to such questions
-[clrs2001]. Namely,
-an invariant should be maintained whereby
-each node should contain also the
-maximal endpoint of any interval within its subtree, as in Figure
-
-Sets of line intervals
--B. In order to maintain this ivariant, though, an invariant-restoring policy is
-required.
-
- The underlying data structure affects what the function can do with the container object.
-
-
-
- For example, if Cntnr is std::map, then the function can
-use std::for_each(r_cnt.find(foo), r_cnt.find(bar), foobar)
-in order to apply foobar to all elements between foo
-and bar. If Cntnr is a hash-based container, then this call's results are undefined.
-
-
-
- Also, if Cntnr is tree-based, the type and object of the comparison functor
-can be accessed. If Cntnr is hash based, these queries are nonsensical
-
-
- These types of problems are excaberated when considering the wide variety of useful underlying data-structures. Figure
-Different underlying data structures
-shows different underlying data-structures (the ones
-currently supported in pb_assoc). A shows a collision-chaining hash-table; B shows a probing hash-table; C shows a red-black tree; D shows a splay tree; E shows a tree based on an ordered vector (the tree is implicit in the order of the elements); E shows a list-based container with update policies.
-
- These underlying data structures display different behavior. For one, they can be queried for different policies. Furthermore:
-
-
-
- Containers based on C, D, and E store eleents in a meaningful order; the others store elements in a meaningless (and probably time-varying) order. As a futher consequence, containers based on C, D, and E can support erase operations taking an iterator and returning an iterator to the following element; the others cannot.
-
-
- Containers based on C, D, and E can be split and joined efficiently, while the others cannot. Containers based on C and D, futhermore, can guarantee that this is exception-free; containers based on E cannot guarantee this.
-
-
- Containers based on all but E can guarantee that erasing an element is exception free; containers based on E cannot guarantee this. Containers based on all but B and E can guarantee that modifying an object of their type does not invalidate iterators or references to their elements, while contianers based on B and E cannot. Containers based on C, D, and E can futhermore make a stronger guarantee, namely that modifiying an object of their type does not affect the relation of iterators.
-
-
-
-
- A unified tag and traits system (as used for the STL's iterators, for example) can ease generic manipulation of associative containers based on different underlying data-structures.
-
- In some cases, map and set semantics are inappropriate. E.g., consider
-an application monitoring user activity. Such an application might be designed to track a user, the machine(s) to which the user is logged, application(s) the user is running on the machine, and the start time of the application. In this case, since a user might run more than a single application, there can be no unique mapping from a user to specific datum.
-
-
-
- The STL's non-unique mapping containers (e.g.,
-std::multimap and std::multiset) can be used
-in this case. These types of containers can store store two or more equivalent, non-identical keys [kleft00sets]. Figure
-Non-unique mapping containers in the STL's design shows possible structures of STL tree-based and hash-based containers, multisets, respectively; in this figure, equivalent-key nodes share the same shading.
-
-Non-unique mapping containers in the STL's design.
-
-
-
- This design has several advantages. Foremost, it allows maps and multimaps, and sets and multisets, to share the same value_type, easing generic manipulation of containers with different mapping semantics.
-
As mentioned before, there are several underlying data-structures, each with its set of tradeoffs.
-The STL's design uses an associative linked-list to store all elements with equivalent primary
-key (e.g., users). Searching for a secondary key (e.g.,
-a process) is inherently linear. While this works reasonably well when the number of distinct secondary
-keys is small, it does not scale well.
-
-
Embedding linked lists can cause the entire structure to be inefficient.
-E.g., Figure
-
-Effect of embedded lists in STL multimaps
--A
- shows a tree with several shaded nodes containing equivalent keys; note how unbalanced
-this tree would seem when considering all shaded nodes to be a single node.
-Figure
-
-Effect of embedded lists in STL multimaps
--B shows a hash table with several shaded nodes containing equivalent keys; note
-that this can lengthen the search for other nodes as well.
-
-
Embdedding linked lists is only possible for some data structures.
-Some data structures, e.g., probing-hash tables, linear hash tables,
-and extendible hash tables, cannot support it.
-
-
The embedded linked list design forgoes the abilitiy to treat
-all elements with the same primary key as a single entity. The ability to
-efficiently simultaneously insert (or erase) a larger number of elements with
-the same primary key is lost; the ability to utilize segmented iterators is lost
-[austern98segmented].
-
-
The linked-list design uses much space. For one, in the above example, the data identifying will must be duplicated for each application run by the user. Furthermore, the "links" in the linked list are supplied by the underlying data structure. In the case of tree-based containers, for example, the linked list utilizes the fact that each tree node contains pointers to its parent and its children; given that the order of equivalent keys is meaningless, the number of pointers exceeds the functionality supplied by a linked list.
-
- [meyers02both] points out
-that a class's methods should comprise only operations which depend on the class's internal structure; other operations are best designed as external functions. Possibly, therefore, the STL's associative containers lack some useful methods, and provide some redundant methods.
-
-
-
-
- Possibly missing methods:
-
-
-
- It is well-known that tree-based container objects can be efficiently split or joined
- [clrs2001]. Externally splitting or joining trees is super-linear, and, furthermore, can throw exceptions. Split and join methods, consequently, seem good choices for tree-based container methods.
-
-
- Suppose all elements which match a certain criteria need to be erased from an
-unordered container object, e.g., all elements whos keys are in a given range. Externally erasing them from the container object is super-linear, since erasing an element might reorder all iterators. Conditional erasing, therefore, seems a good choice for associative containers.
-
-
-
Possibly redundant methods:
-
-
- STL associative containers provide methods for inserting a range of elements given by a pair of iterators. At best, this can be implemented as an external function, or, even more efficiently, as a join operation (for the case of tree-based containers). Moreover, these methods seem similar to constructors taking a range given by a pair of iterators; the constructors, however, are transactional, whereas the insert methods are not; this is possibly confusing.
-
-
- STL associative containers provide methods for erasing a range of elements given by a pair of iterators. At best, this can be implemented as an external function, or, even more efficiently, as a (small) sequence of split and join operations (for the case of tree-based containers). Moreover, the results of erasing a range is undefined for the case of containers based on unordered data-structures.
-
-
- Associative containers are parameterized by policies allowing to test keys, but not data, for equivalence. When comparing two associative container objects, it is at least as reasonable to expect that they are equivalent if both keys and data are equivalent, as it is reasonable to expect that they are equivalent if their keys only are equivalent. Furthermore, in different settings it makes sense that two objects are equivalent if they store keys in the same order, whereas in other settings order does not matter. The operators operator== and operator!= are not descriptive enough for these considerations.
-
-Motivation::Mapping Semantics discussed scalability issues with the STL's non-unique-mapping associative containers; non-unique association inherently embeds linked-lists in associative containers resulting in scalability problems and other problems.
-
-
-
- In pb_assoc, all containers have unique-key semantics. Each key is uniquely mapped to "something".
-
- There are no separate classes for maps, sets, multimaps, and multisets (as the STL has). Rather, the mapping-semantic is set by specifying the Key parameter.
-
-
-
-
If Data is any type (e.g., int or
-std::string), then the container is a "map" - it maps each Key object to a Data object.
-
-
If Data is
-null_data_type,
-then the container is a "set" - it stores each Key object. In this case, each Key object is not really mapped to anything (except, implicitly, to the fact that it is stored in the container object).
-
-
- If Data is
-compound_data_type<Cntnr>,
-then the container is a "multimap" - it maps each Key object into a Cntnr object. This structure is recursive - Cntnr itself can be a "map", "set", "multimap", and so forth.
-
-
-
-
- Each container derives from one of the three containers
-in the oval of Figure
-
-Data-types as a policy
-.
-
-
-
-
basic_assoc_cntnr
-is the base for most instantiations of a container's Data paramter. This
-base includes the definition of data_type, and supports
-operator[].
-
-
basic_assoc_cntnr is the base for a
-null_data_type instantiation of a container's Data paramter. This
-base lacks the definition of data_type, and does not support
-operator[].
-
basic_assoc_cntnr is the base for a
-compound_data_type<Cntnr> instantiation of a container's Data paramter. This
-base includes the definition of data_type, and supports
-operator[]. It further supports some advanced functionality described in the remainder of this section.
-
- Consider a pb_assoc "multimap" mapping integers to characters.
-Since a pb_assoc "multimap" is a "map" of "sets",
-if m is an object of this type, it is not possible to directly use
-m.insert(std::make_pair(2, 'b') (however, it is possible to directly use
-m[2].insert('b')). In would be nice if this method whould be supported.
-
-
-
- Put differently, while the pb_assoc "multimap" can be viewed logically as the collection
-
-
- { int → {char} },
-
-
- It would be nice if it could simultaneously be viewed as the collection
-
-
- { (int, char) },
-
-
i.e., a "set" of pairs.
-
-
- In more general terms, it would be nice to be able to simultaneously
-view a collection
-
- Each associative container in pb_assoc has
-a mapping level. The mapping level is defined by
-the instantiation of a container's Data
-parameter:
-
-
-
-
If the Data parameter is instantiated
-by
-null_data_type (i.e.,
-the container is a "set"), then the mapping level is 1.
-
-
If the Data parameter is instantiated
-by
-compound_data_type<Cntnr>
-(i.e., the container is a "multimap"), then the mapping level
-is 1 + the mapping level of Cntnr.
-
-
If the Data parameter is instantiated
-by any other type, e.g., char (i.e.,
-the container is a "map"), then the mapping level is 1.
-
-
-
-
- Containers can be rebound, at compile time, to different mapping levels.
-The compound data-type specialization basic_assoc_cntnr
-defines internally
-
-(which is similar to the STL's allocator rebind mechanism).
-the type other is the view of the container with mapping
-level Mapping_Level. The container can be safely cast
-to other.
-
- It is, of course, beneficial to query types for their mapping semantics.
-
-
-
- Each container defines internally the type ms_category
-as its mapping-semantics tag (hopefully this name is not copyrighted
-by some major corporation). The possible tags, shown in Figure
-
-are the following:
-
-
-
-
- basic_ms_tag
-is a basic mapping-semantics tag. It is the type defined by "set"s.
-
-
- data_enabled_ms_tag
-is a mapping-semantics tag of types that have data. It is the type defined by "map"s.
-
-
- compound_data_enabled_ms_tag
-is a mapping-semantics tag of types that have compound data. It is the type defined by "multimap"s.
-
-
-
-
- Additionally, a container's mapping semantics can be queried by traits. For any
-container Cntnr,
-
-
-pb_assoc's mapping-semantics design has some drawbacks compared to that of the STL.
-
-
-
Equivalent, Non-Identical Keys
-
-
- The STL's multimaps and multisets allow storing equivalent, non-identical keys
-[kleft00sets]. For example, assume a bank maintains a data structure monitoring the accounts opened by each person. This could be modeled as the following:
-
-
-
-// Name type.
-typedef
- std::string
- name;
-
-// Account-id type.
-typedef
- unsigned long
- account_id;
-
-// Association between a name and an account id.
-class opened_info
-{
-public:
- ...
-
- // Comparison operator.
- bool
- operator<
- (const opened_info &r_other)
- {
- Comparison is defined as the comparison of the names.
- return m_name < r_other.m_name;
- }
-
-
-private:
- name m_name;
-
- account_id m_acc_id;
-};
-
-// A multiset of opened accounts.
-typedef
- std::multiset<
- opened_info>
- all_opened_info;
-
-
-
- std::multiset can accomodate multiple equivalent, non-identical opened_info - those with the same name but different account id.
-
-
-
- In pb_assoc, however, non-unique mapping is unsupported. The equivalent to the above could be
-
- The drawback lies in the fact that the data stored in
-all_opened_info is less encapsulated - an opened_info
-object needs to be constructed when a specific name and account are found, and
-an opened_info object needs to be decomposed into name and
-account_id objects when it is inserted into a all_opened_info
-object.
-
-
-
- It should be noticed however, that the above drawbacks - construction and decomposition are constant-time additive drawbacks. The drawbacks of the
-STL's associative containers are in terms of orders of growth.
-
-
-
Definition of value_type
-
-
- The STL's associative containers contain a pleasingly uniform definition of
-the value_type of a container.
-If a container is parameterized by key as its Key, and data as its Data, then its value_type is
-std::pair<const key, data>;
-for example, the value_type of std::map<int, char> is
-std::pair<const int, char>. Futhermore, the value_type of a container and the value_type of the container's iterators are identical.
-
-
-
- In pb_assoc, conversely, the rules are more complex.
-
-
-
For one, a container's
-value_type is, in general
-std::pair<const Key, Data>,
-but if Data is null_data_type, then the value_type
-is
-Key,
-and if
-Data is
-compound_data_type<Cntnr>, then the value_type is
-std::pair<const Key, Cntnr>.
-
-
-
- Futhermore, assume that Cntnr is an associative container with more than a single mapping level, and let Cntnr_ be defined as
-
-i.e., the container rebound to a different mapping level.
-In this case, the value_type of the rebound container is not the value_type
-of the rebound container's iterators. I.e., it is not true that
-typename Cntnr_::value_type is the same as
-typename Cntnr_::iterator::value_type. This complication never exists for the STL's container.
-
- Figure
-Some node invariants
-shows some node invariants. A shows
-a tree whose each node contains, asides from an double key, the number
-of nodes at the subtree rooted at the node; B shows a tree whose each node
-contains, asides from a line-interval key, the maximal endpoint of the interval
-of any node in the subtree rooted at the node.
- The first tree allows querying efficiently what is the order statistic
-of any element; the second tree allows querying efficiently if any, or which,
-intervals overlap a given interval.
-
- Maintaining such trees is difficult, for two reasons:
-
-
-
Various operations can invalidate node invariants.
-E.g., Figure
-Invalidation of node invariants
-shows how a right rotation, performed on A, results in B, with nodes x
-and y having corrupted invariants (the greyed nodes in C);
-Figure
-Invalidation of node invariants
-shows how an insert, performed on D, results in E, with nodes x
-and y having corrupted invariants (the greyed nodes in F).
- It is not feasible to know outside the tree the effect of an operation on the
-nodes of the tree.
-
-
- Even if node invariants are maintained, it is not possible to know
-in advance which search paths are required (e.g., searching for all
-line intervals overlapping some interval might require several search paths).
-
- These problems are solved by a combination of two means:
-
-
-
-
- The tree-based containers are parameterized by a Node_Updator
-parameter. When a tree operation might invalidate some node invariant,
-a Node_Updator object is invoked to restore the invariant. This object is
-always invoked with three nodes: some node, say x in
-Figure
-Invalidation of node invariants-A
-has an invalid invariant, but its children, y and z hav valid invariants.
-After the invocation, all three nodes have valid invariants, as
-in
-Figure
-Invalidation of node invariants-B.
-It is well known that any insert, erase,
-split or join, can restore
-all node invariants by a small number of node invariant updates
-[clrs2001].
-For example, Figure
-
-Insert update sequence diagram
-
-shows an insert operation (point A); the tree performs some operations, and
-calls the update functor three times (points B, C, and D).
-
-
- The tree based containers all define internally node_iterator
- and const_node_iterator, iterators which can be used to traverse
- from a node to any of its children or parent.
-
- In
-Null Policy Classes
-a distinction was made between redundant policies
-and null policies.
-
-
-
- Seemingly, in this case a redundant policy - a policy which doesn't
-affect nodes' contents would suffice in this case. This, however, would
-lead to performance loss.
-Figure
-
-Rationale for null node-invariant functors
-
-shows a typical case where invariants are restored (in this case, to the
-shaded node). In most cases, tree operations such as rotations affect only
-the lower levels of the tree. A null policy allows to know that there
-is no need to traverse the tree to the root.
-
- In pb_assoc, all associative containers have a unique-key design;
-each container can have at most one entry for any given key. Multimaps
-are designed as maps from keys to sets; multisets are designed as maps from
-keys to non-negative integral types.
-
- The STL's design of associative containers elegantly allows
-generic manipulation of containers: each container defines
-data_type as the domain of its data;
-value_type as the domain of its relationship. This is not
-directly applicable in pb_assoc. Consider
-a multimap mapping Key objects to
-Data_Coll objects, where
-Data_Coll is some set-type of Data.
-Then should the multimap's value_type should be
-std::pair<Key, Data> or
-std::pair<Key, Data_Coll>, for example?.
-
-
-
- pb_assoc addresses this by differentiating
-between the domain and the type of relationship.
-All associative containers define value_type as
-the relationship's domain, and mapped_value_type as its
-type. E.g., both
-map types and multimap types may share the same value_type,
-if they map from the same key domain to
-the same data domain. In this case, however, they will not share
-the same mapped_value_type, since the multimap type maps from the
-key domain to the domain of collections of data. The same
-differentiation exists between the domain and type of mapped data.
-
-
-
- In general, the following types describe the relationships
-of each associative container:
-
-
-
- key_type- This describes the domain of the keys of the container. All
- associative containers define this type.
-
-
- data_type- This describes the domain of the data mapped by a
- key. It is identical to the data_type defined by std::map, std::set,
- std::multimap, and std::multiset. Sets and multisets do not
- define this type, since they map each key to the abstract fact that the key is
- stored by them.
-
-
- mapped_data_type- This describes the type of the data mapped by
- a key. For maps, this is the same as data_type. For multimaps, this is
- not the same as data_type; The mapped_data_type describes the
- collection of data_types used. Sets do not define this type. For
- multisets, the mapped_data_type describes the unsigned integral type
- used to indicate the number of occurrences of a key.
-
-
- value_type- This describes the domain of relationships store in
- a container. It is identical to the value_type defined by std::map,
- std::set, std::multimap, and std::multiset.
-
-
- mapped_value_type- This describes the type of relationships
- store in a container. It consists of information on the key_type and mapped_data_type
- (except for sets).
-
-
-
-
- The following table defines the above types for a map
-mapping from Key types to Data types:
-
-
-
-
type
-
Description / Definition
-
-
-
key_type
-
-
Key
-
-
-
-
data_type
-
-
Data
-
-
-
-
mapped_data_type
-
-
Data
-
-
-
-
value_type
-
-
std::pair<const Key, Data>
-
-
-
-
mapped_value_type
-
-
std::pair<const Key, Data>
-
-
-
-
-
-
The following table defines the above types for a
-set storing Key types:
-
-
-
type
-
Description / Definition
-
-
-
key_type
-
-
Key
-
-
-
-
data_type
-
-
-
-
-
-
mapped_data_type
-
-
-
-
-
-
value_type
-
-
const Key
-
-
-
-
mapped_value_type
-
-
const Key
-
-
-
-
-
The following table defines the above types for a multimap
-mapping from Key types to Data_Coll<Data>
-types, where Data_Coll<Data>
-is a set of Data types:
-
-
-
type
-
Description / Definition
-
-
-
key_type
-
-
Key
-
-
-
-
data_type
-
-
Data
-
-
-
-
mapped_data_type
-
-
Data_Coll<Data>
-
-
-
-
value_type
-
-
std::pair<const Key, Data>
-
-
-
-
mapped_value_type
-
-
std::pair<const Key, Data_Coll<Data> >
-
-
-
-
-
The following table defines the above types for a multiset
-storing Key types:
-
-
-
type
-
Description / Definition
-
-
-
key_type
-
-
Key
-
-
-
-
data_type
-
-
-
-
-
-
mapped_data_type
-
-
size_type
-
-
-
-
value_type
-
-
std::pair<const Key, size_type>
-
-
-
-
mapped_value_type
-
-
const Key
-
-
-
-
-
- The above types allow to define simple invariants on the interfaces of
-containers. For example, each container defines both an insert method
-which takes a const reference to a value_type, and an insert method
-which takes a const reference to a mapped_value_type. Containers for
-which both these types are synonymous (i.e., maps and sets), consequently
-have a
-single insert method. Containers for which these types are distinct (i.e.,
-multimaps and multisets), use overloading.
-
- In some cases, it is necessary, given a container and an iterator, to query the
-iterator' value_type to the container's value_type and mapped_value_type.
-The classes
-is_mapped_value_iterator
-and iterator_key can be used for this.
-
-
-
- The STL's std::multimap and std::multiset allow iterating
-over all value_types stored in them, which is convenient. The library
-provides a value_iterator for this.
-This is an iterator adapter over the containers' native iterators.
-
- The STL allows using equivalent, non-identical, keys.
-For example, let interval be a line-interval class,
-color be a
-color type, thickness be a thickness type, and colored_interval
-be a class composed of an interval and a color.
-
-
-
- Suppose one wants to store colored_interval
-objects using a comparison predicate ignoring colors. Then
-in the STL's design, one would use
-multiset<colored_interval>; in pb_assoc's design,
-one would use one of the following:
-
-
-
- A map mapping interval objects to
-color objects. This, however, assumes that
-colored_interval is decomposable to, and constructible from,
-interval and color.
-
-
- A map mapping colored_interval objects to
-color objects. In this (less efficient) case, a colored_interval object
-is a "representative" of all colored intervals with the same endpoints.
-
-
-
-
- Suppose one wants to map colored_interval
-objects to thickness objects
-using a comparison predicate ignoring colors. Then
-in the STL's design, one would use
-multimap<colored_interval, thickness>; in pb_assoc's design,
-one would use one of the following:
-
-
-
A map mapping interval objects to
-std::pair<color, thickness> objects. This, however, assumes that
-colored_interval is decomposable to, and constructible from,
-interval and color.
-
-
A map mapping colored_interval objects to
-std::pair<color, thickness> objects. In this (less efficient) case, a colored_interval object
-is a "representative" of all colored intervals with the same endpoints.
-
-
-
-
-(From the above, it is apparent that the STL's design has an advantage
-over pb_assoc's design in terms of convenience. Nonethless, there
-are efficiency limitation in the STL's design (see
-Unique-Key Design for Multimaps and Multisets).)
-
-
-
- The above example, using intervals, colors and thicknesses, can be generalized.
-Let
-key_unique_part be a unique part of some key
-(e.g., interval in the above),
-key_non_unique_part be a non-unique part of some key
-(e.g., color in the above),
-key be some key composed of unique and non-uniqe parts
-(e.g., colored_interval in the above),
-and
-data be some data
-(e.g., thickness in the above).
-Then the
-figure shows some
-STL containers and the pb_assoc counterparts.
-
-
-
Returns the order of a key within a sequence. For exapmle, if r_key is the smallest key in r_c, this method will return 0; if r_key is a key between the smallest and next key in r_c, this method will return 1; if r_key is a key larger than the largest key in r_c, this method will return the size of r_c.
- The Introduction Section described some challenges
-in designing associative containers. This section describes the pb_assoc's solution.
-
-
-
-
-Figure
-Class hierarchy
-shows a class diagram of pb_assoc's associative containers.
-Associative container classes subclass other associative container classes such that
-base classes capture common types and methods
-[stroustrup97cpp]. The type hash_fn is defined in basic_hash_assoc_cntnr, for example, since all hash-based containers employ a hash function;
-cc_hash_assoc_cntnr
-and
-gp_hash_assoc_cntnr,
-subclasses encapsulating a collision-chaining and (general) probing hash table, respectively, each define other types specific for their underlying data-structure.
-This is described further in
-Data-Structure Genericity.
-
- It is sometimes useful to know the underlying data-structure.
-Associative containers internally define ds_category as a class describing this. Two classes might be different instantiations
-of
-tree_assoc_cntnr, but one might be based on a red-black tree while another might be based on a splay tree. (This might affect the way tree objects should be manipulated.) typename Cntnr::ds_category
-yields a "tag" class for the underlying data-structure of some type
-Cntnr.
-This is described further in
-Data-Structure Genericity.
-
-
-
- When manipulating generic containers, it is useful to know which types, methods, and guarantees they support. For example, tree-based containers can support split and join operations, while containers based on most other underlying data-structures cannot.
-These questions can be answered in compile time through a traits mechanism.
-ds_traits<Cntnr>::split_join, for example, answers the above question.
-This is described further in
-Data-Structure Genericity;
-ds_traits_example.cpp-
-shows an example.
-
-
-
- pb_assoc does not contain separate containers for different mapping semantics,
-as the STL does (e.g., std::map and std::multimap). Rather, containers are parameterized by a Data parameter, and this parameter is a policy for the mapping semantics.
-
-
-
- Instantiating a container's Data parameter by all but two distingished types, will make a "map". Thus
-
- Instantiating a container's Data parameter by compound_data_type<Cntnr>, where Cntnr is a different associative container, will make a "(multi)+map". Thus
-
- is a type
-mapping each int value to a "set" of char
-values.
-basic_multimap_example.cpp shows an example.
-This composition is recursive, however, and more complex relationships can be built.
-mapping_level_example.cpp shows an example.
-
-
-
-
- The associative-container classes derive each from one of the three
-basic_assoc_cntnr classes, depending
-on the data policy. These three base classes define different types and methods. For example, the "map" specialization of
-basic_assoc_cntnr
-defines operator[], wherase the "set" specialization does not.
-This is described further in
-Mapping-Semantic Genericity.
-
-
-
- pb_assoc's design contains the concept of a mapping level. "Map" and "set" types have a single mapping level; A container
-mapping integers to "maps" mapping characters to floats has two mapping levels, since it can be viewed as a type mapping each integer to a "map", or as a type mapping each pair of integer and character to a float. pb_assoc contains traits and rebind mechanisms for querying and altering the mapping levels.
-This is described further in
-Mapping-Semantic Genericity.
-
-
-
- The leaf classes in Figure
-Class hierarchy
-are each parameterized by policies, easing configuring containers for different settings.
-Hash-Based Containers describes the design and policies of hash-based containers,
- Tree-Based Containers describes the design and policies of tree-based containers, and
- List-Based Containers describes the design and policies of list-based containers with update policies.
-
-
Signifies an invalidation guarantee that includes all those of its base, and additionally, that any range-type iterator (including the returns of begin() and end()) is in the correct relative positions to other range-type iterators as long as its corresponding entry has not be erased, regardless of modifications to the container object.
-
[alexandrescu01modern] Andrei Alexandrescu, Modern C++ Design: Generic Programming and Design Patterns Applied, Addison-Wesley Publishing Company, 2001
-
-
[andrew04mtf] K. Andrew and D. Gleich, "MTF, Bit, and COMB: A Guide to Deterministic and Randomized Algorithms for the List Update Problem"
-
-
[austern00noset] Matthew Austern, "Why You shouldn't use set - and What You Should Use Instead", C++ Report, April, 2000
[dubhashi98neg] D. Dubashi, and D. Ranjan, "Balls and bins: A study in negative dependence.", Random Structures and Algorithms 13, 2 (1998), 99-124
-
-
[fagin79extendible] R. Fagin, J. Nievergelt, N. Pippenger, and H. R. Strong, "Extendible hashing — a fast access method for dynamic files", ACM Trans. Database Syst. 4, 3 (1979), 315-344
-
-
[gamma95designpatterns] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, "Design Patterns - Elements of Reusable Object-Oriented Software", Addison-Wesley Publishing Company, Addison-Wesley, 1995
-
-
[garg86order] A. K. Garg and C. C. Gotlieb, "Order-preserving key transformations", Trans. Database Syst. 11, 2 (1986), 213-234
[hyslop02making] J. Hyslop, and H. Sutter, "Making a real hash of things", C++ Report, May 2002
-
-
[jossutis01stl] N. M. Jossutis, "The C++ Standard Library - A Tutorial and Reference", Addison-Wesley Publishing Company, Addison-Wesley, 2001
-
-
[kleft00sets] Klaus Kleft and Angelika Langer, "Are Set Iterators Mutable or Immutable?", C/C++ Users Jornal, October 2000
-
-
[knuth98sorting] D. E. Knuth, "The Art of Computer Programming - Sorting and Searching", Addison-Wesley Publishing Company, Addison-Wesley, 1998
-
-
[liskov98data] B. Liskov, "Data abstraction and hierarchy", SIGPLAN Notices 23, 5 (May 1998)
-
-
[litwin80lh] W. Litwin, "Linear hashing: A new tool for file and table addressing", Proceedings of International Conference on Very Large Data Bases (June 1980), pp. 212-223
-
-
[metrowerks_stl], "Metrowerks CodeWarrior Pro 7 MSL C++ Reference Manual",
-
-
[meyers96more] S. Meyers, "More Effective C++: 35 New Ways to Improve Your Programs and Designs - 2nd ed.", Addison-Wesley Publishing Company, Addison-Wesley, 1996
[meyers01stl] S. Meyers, "Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library", Addison-Wesley Publishing Company, Addison-Wesley, 2001
-
-
[meyers02both] S. Meyers, "Class Template, Member Template - or Both?", C/C++ Users Journal, 2003
-
-
[motwani95random] R. Motwani, and P. Raghavan, "Randomized Algorithms", Cambridge University Press
[sleator84amortized] D. D. Sleator and R. E. Tarjan, "Amortized Efficiency of List Update Problems", ACM Symposium on Theory of Computing, 1984
-
-
[sleator85self] D. D. Sleator and R. E. Tarjan, "Self-Adjusting Binary Search Trees", ACM Symposium on Theory of Computing, 1985
-
-
[stepanov94standard] A. A. Stepanov and M. Lee", "The Standard Template Library"
-
-
[stroustrup97cpp] Bjarne Stroustrup, The C++ Programming Langugage -3rd ed., Addison-Wesley Publishing Company,Reading, MA, USA, 1997
-
-
[vandevoorde2002cpptemplates] D. Vandevoorde, and N. M. Josuttis, "C++ Templates: The Complete Guide", Addison-Wesley Publishing Company, Addison-Wesley, 2002
- Hash-tables, as opposed to trees, do not naturally grow or shrink. It
-is necessary to specify policies to determine how and when a hash table should change
-its size.
-
-
-
- In general, resize policies can be decomposed into (probably orthogonal)
-policies:
-
-
-
A size policy indicating how a hash table should
-grow (e.g., it should multiply by powers of 2).
-
-
A trigger policy indicating when a hash table should
-grow (e.g., a load factor is exceeded).
-
- Size policies determine how a hash table
-changes size. These policies are simple, and there are relatively
-few sensible options. An exponential-size policy (with the initial
-size and growth factors both powers of 2) works well with a
-mask-based range-hashing function (see the Range-Hashing Policies subsection),
-and is the
-hard-wired policy used by Dinkumware
-[dinkumware_stl]. A
-prime-list based policy works well with a modulo-prime range
-hashing function (see the Range-Hashing Policies subsection),
-and is the
-hard-wired policy used by SGI's implementation
-[sgi_stl].
-
- Trigger policies determine when a hash table changes size.
-Following is a description of two polcies: load-check
-policies, and a collision-check policies.
-
-
-
- Load-check policies are straightforward. The user
-specifies two factors, αmin and αmax, and
-the hash table maintains the invariant that
-
- Collision-check policies work in the opposite direction of
-load-check policies. They focus on keeping the number of
-collisions moderate and hoping
-that the size of the table will not grow very large,
-instead of keeping a moderate load-factor and
-hoping that the number of collisions will be small.
-A
-maximal collision-check policy resizes when the shortest
-probe-sequence grows too large.
-
-
-
-
- Consider Figure
-Balls and bins.
- Let the size of the hash table be denoted by m, the
-length of a probe sequence be denoted by k, and some load
-factor be denoted by α. We would like to calculate the
-minimal length of k, such that if there were α m elements
-in the hash table, a probe sequence of length k would be found
-with probability at most 1/m.
-
- Denote the probability that a probe sequence of length k
-appears in bin i by pi, the length of the probe sequence
-of bin i by li, and assume uniform distribution.
-Then
-
- where (a) follows from the Chernoff bound
-[motwani95random].
-To
-calculate the probability that some bin contains a probe
-sequence greater than k, we note that the li are
-negatively-dependent
-[dubhashi98neg].
-Let I(.)
-denote the indicator function. Then
-
-where (a) follows from the fact that the Chernoff bound can be
-applied to negatively-dependent variables
-[dubhashi98neg].
-Inserting (2) into
-(3), and equating with 1/m,
-we obtain
-
- The resize policies in the previous subsection are conceptually straightforward. The design
-of hash-based containers' size-related interface is complicated by some factors.
-
-
-
Most containers, i.e. lists, trees, and vectors, have a single "size" concept. There is no
-distinction between the number of entries the container holds and the number of entries it is using. This,
-of course, is not the case for hash-based containers. Moreover, even describing the
-"actual" size of a hash-based container (as opposed to its logical size) is difficult - a probing-based container
-holds entries to elements, even those it does not use, while a chaining-based container holds pointers to entries.
-
-
- The policies mentioned above operate in terms of invariants. E.g. a load-check trigger policy
-maintains an invariant concerning the load factor of a container object. This is sometimes too rigid:
-
-
In some cases it is desirable to allow controlled override of an entire policy, e.g. by externally resizing a container object (or giving it an initial size, which is a special case of externally resizing the container).
-
-
- In other cases it is desirable to allow changing the specifics of a policy in runtime, e.g., changing the load factors of a load-check policy.
-
-
-
-
- Resize policies interact strongly with hash policies. Performance-wise, for example, it is undesirable to use an exponential size policy of powers of two with a modulo range-hashing function, and it is undesirable to use a prime size policy with a mask range-hashing function. In other cases, the effects are more dramatic. For example, using a quadratic probe function with an exponential size policy will probably cause cases where the container object has available entries which are never reached by the probe function. (Hash Policies
-discusses the previous concepts.)
-
-
-
-
- Clearly, the more of these points an interface addresses, the greater its flexibility but the lower its encapsulation and uniformity between associative containers.
-
-
-
-
-
- This library attempts to address these types of problems by delegating all size-related functionality to
-policy classes. Hash-based containers
-are parameterized by a resize-policy class (among others), and derive publicly from
-the resize-policy class
-[alexandrescu01modern]
- E.g., a collision-chaining
-hash table is defined as follows:
-
-
-cc_ht_map<
- class Key,
- class Data,
- ...
- class Resize_Policy
- ...> :
- public Resize_Policy
-
-
-
- The containers themselves lack any functionality or public interface for manipulating sizes. A container
-object merely forwards events to its resize policy object and queries it for needed actions.
-
-
-
- Figure
-
-Insert resize sequence diagram
-
-shows a (possible) sequence diagram of an insert operation.
-The user inserts an element; the hash table
-notifies its resize policy that a search has started (point A);
-in this case, a single collision is encountered - the table
-notifies its resize policy of this (point B); the container
-finally notifies its resize policy that the search has ended (point C);
-it then queries its resize policy whether a resize is needed, and if so,
-what is the new size (points D to G); following the resize, it notifies
-the policy that a resize has completed (point H); finally, the element
-is inserted, and the policy notified (point I).
-
- This addresses, to some extent, the problems mentioned above:
-
-
-
- Different instantiations of range-hashing policies can be met with different instantiations of
- resize policies.
-
-
- Questions on size-related interface are avoided, since the containers have no size-related methods. Thus
- a container has no method for querying its actual size. It merely continuously forwards enough information to
- its resize policy to answer such queries; the designer of the resize policy can decide whether, or how, to design the appropriate method. Also, a container has no methods for setting its size. It merely queries its
-resize policy for an initial size, queries it on a new size (if the resize policy indicates a resize is needed), and
-supports a protected virtual function for external resize.
-
-
-
-
- The library contains a single class for instantiating a resize policy,
-pb_assoc contains
-a standard resize policy,
-hash_standard_resize_policy (the name is explained shortly).
-In terms of interface, it is parameterized by a boolean constant indicating whether its public interface supports
-queries of actual size and external resize operations (the inclusion and exclusion of these methods in the interface have obvious tradeoffs in terms of encapsulation and flexibility).
-([alexandrescu01modern] shows many techniques for
-changing between alternative interfaces at compile time.)
-
-
-
-As noted before,
- size and trigger policies are usually orthogonal.
-hash_standard_resize_policy
-is parameterized by size and trigger policies. For example,
-a collision-chaining hash table
-is typically be defined as follows:
-
Constructor taking some policy objects. r_cmp_fn will be copied by the Cmp_Fn object of the container object, and r_node_updator will be copied by the Node_Updator object of the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- tree_assoc_cntnr
- (It first_it,
- It last_it)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types. The value_types between first_it and last_it will be inserted into the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- tree_assoc_cntnr
- (It first_it,
- It last_it,
- constcmp_fn &r_cmp_fn)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types and some policy objects The value_types between first_it and last_it will be inserted into the container object. r_cmp_fn will be copied by the Cmp_Fn object of the container object.
-
-
-
-
-
-
-
-
-
template<
- class It>
- tree_assoc_cntnr
- (It first_it,
- It last_it,
- constcmp_fn &r_cmp_fn,
- constNode_Updator &r_node_updator)
-
-
-
-
-
-
Constructor taking iterators to a range of value_types and some policy objects The value_types between first_it and last_it will be inserted into the container object. r_cmp_fn will be copied by the Cmp_Fn object of the container object, and r_node_updator will be copied by the Node_Updator object of the container object.
DS_Tag specifies which underlying data-structure to use, and is described shortly.
-
Node_Updator is a policy for updating node invariants.
-This is described in Node Invariants.
-
-
Allocator is (surprisingly) an allocator type.
-
-
-
-
- The DS_Tag specifies which underlying data-structure to use.
-Instantiating it by
-rb_tree_ds_tag,
-splay_tree_ds_tag,
-or
-ov_tree_ds_tag,
-specifies an undelying
-red-black tree,
-splay tree,
-or
-ordered-vector tree.
- any other tag is illegal. Note that containers based on the former two contain more types and methods than the latter (e.g., reverse_iterator and rbegin), and different exception and invalidation guarantees.
-
- Figure
-Some node invariants
-shows some node invariants. A shows
-a tree whose each node contains, asides from an double key, the number
-of nodes at the subtree rooted at the node; B shows a tree whose each node
-contains, asides from a line-interval key, the maximal endpoint of the interval
-of any node in the subtree rooted at the node.
- The first tree allows querying efficiently what is the order statistic
-of any element; the second tree allows querying efficiently if any, or which,
-intervals overlap a given interval.
-
- Maintaining such trees is difficult, for two reasons:
-
-
-
Various operations can invalidate node invariants.
-E.g., Figure
-Invalidation of node invariants
-shows how a right rotation, performed on A, results in B, with nodes x
-and y having corrupted invariants (the greyed nodes in C);
-Figure
-Invalidation of node invariants
-shows how an insert, performed on D, results in E, with nodes x
-and y having corrupted invariants (the greyed nodes in F).
- It is not feasible to know outside the tree the effect of an operation on the
-nodes of the tree.
-
-
- Even if node invariants are maintained, it is not possible to know
-in advance which search paths are required (e.g., searching for all
-line intervals overlapping some interval might require several search paths).
-
- These problems are solved by a combination of two means:
-
-
-
-
- The tree-based containers are parameterized by a Node_Updator
-parameter. When a tree operation might invalidate some node invariant,
-a Node_Updator object is invoked to restore the invariant. This object is
-always invoked with three nodes: some node, say x in
-Figure
-Invalidation of node invariants-A
-has an invalid invariant, but its children, y and z hav valid invariants.
-After the invocation, all three nodes have valid invariants, as
-in
-Figure
-Invalidation of node invariants-B.
-It is well known that any insert, erase,
-split or join, can restore
-all node invariants by a small number of node invariant updates
-[clrs2001].
-For example, Figure
-
-Insert update sequence diagram
-
-shows an insert operation (point A); the tree performs some operations, and
-calls the update functor three times (points B, C, and D).
-
-
- The tree based containers all define internally node_iterator
- and const_node_iterator, iterators which can be used to traverse
- from a node to any of its children or parent.
-
- In
-Null Policy Classes
-a distinction was made between redundant policies
-and null policies.
-
-
-
- Seemingly, in this case a redundant policy - a policy which doesn't
-affect nodes' contents would suffice in this case. This, however, would
-lead to performance loss.
-Figure
-
-Rationale for null node-invariant functors
-
-shows a typical case where invariants are restored (in this case, to the
-shaded node). In most cases, tree operations such as rotations affect only
-the lower levels of the tree. A null policy allows to know that there
-is no need to traverse the tree to the root.
-
- For the greater part, using pb_assoc's maps is similar
-to using those of the STL. For example, the following shows a collision-chaining container mapping integers to characters.
-
-
- pb_assoc does not contain separate containers for different mapping semantics,
-as the STL does (e.g., std::map and std::multimap). Rather, containers are parameterized by a Data parameter, and this parameter is a policy for the mapping semantics.
-
-
-
- Instantiating the Data parameter by
-null_data_type
-makes a "set". For example, the following shows a collision-chaining container storing integers.
-
-
The library is based heavily on policy-based design and
+ uses many useful techniques from [alexandrescu01modern].
+
+
Two ideas are borrowed from the SGI-STL implementation
+ [sgi_stl]:
+
+
+
The prime-based resize policies use a list of primes
+ taken from the SGI-STL implementation.
+
+
The red-black trees contain both a root node and a
+ header node (containing metadata), connected in a way
+ that forward and reverse iteration can be performed
+ efficiently.
+
+
+
+
Some test utilities borrow ideas from [boost_timer].
+
+
We would like to thank Scott Meyers for useful comments
+ (without attributing to him any flaws in the design or
+ implementation of the library).
+
+
Much of the documentation is (especially through PyChart, Beautiful
+ Soup, and kjbuckets)
+ and uses . The CSS-driven menus are
+ slightly modified from Brothercake
+ (hopefully without introducing errors).
This section describes performance tests and their results.
+ In the following, g++, msvc++, and local (the build used for generating this
+ documentation) stand for three different builds:
Compiler - g++ (GCC) 4.0.2 20050808 (prerelease)
+ (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software
+ Foundation, Inc. This is free software; see the source
+ for copying conditions. There is NO warranty; not even
+ for MERCHANTABILITY or FITNESS FOR A PARTICULAR
+ PURPOSE.
Compiler - Microsoft (R) 32-bit C/C++ Optimizing
+ Compiler Version 13.10.3077 for 80x86 Copyright (C)
+ Microsoft Corporation 1984-2002. All rights
+ reserved.
Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
+Copyright (C) 2006 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions. There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
Hash-based containers are typically either collision
+ chaining or probing (see Design::Associative
+ Containers::Hash-Based Containers). Collision-chaining
+ containers are more flexible internally, and so offer better
+ timing performance. Probing containers, if used for simple
+ value-types, manage memory more efficiently (they perform far
+ fewer allocation-related calls). In general, therefore, a
+ collision-chaining table should be used. A probing container,
+ conversely, might be used efficiently for operations such as
+ eliminating duplicates in a sequence, or counting the number of
+ occurrences within a sequence. Probing containers might be more
+ useful also in multithreaded applications where each thread
+ manipulates a hash-based container: in the STL, allocators have
+ class-wise semantics (see [meyers96more] - Item 10); a
+ probing container might incur less contention in this case.
In hash-based containers, the range-hashing scheme (see
+ Design::Associative
+ Containers::Hash-Based Containers::Hash Policies) seems to
+ affect performance more than other considerations. In most
+ settings, a mask-based scheme works well (or can be made to
+ work well). If the key-distribution can be estimated a-priori,
+ a simple hash function can produce nearly uniform hash-value
+ distribution. In many other cases (e.g., text hashing,
+ floating-point hashing), the hash function is powerful enough
+ to generate hash values with good uniformity properties
+ [knuth98sorting];
+ a modulo-based scheme, taking into account all bits of the hash
+ value, appears to overlap the hash function in its effort.
In general, there are several families of tree-based
+ underlying data structures: balanced node-based trees
+ (e.g., red-black or AVL trees), high-probability
+ balanced node-based trees (e.g., random treaps or
+ skip-lists), competitive node-based trees (e.g., splay
+ trees), vector-based "trees", and tries. (Additionally, there
+ are disk-residing or network-residing trees, such as B-Trees
+ and their numerous variants. An interface for this would have
+ to deal with the execution model and ACID guarantees; this is
+ out of the scope of this library.) Following are some
+ observations on their application to different settings.
+
Of the balanced node-based trees, this library includes a
+ red-black tree (see Design::Associative
+ Containers::Tree-Based Containers), as does STL (in
+ practice). This type of tree is the "workhorse" of tree-based
+ containers: it offers both reasonable modification and
+ reasonable lookup time. Unfortunately, this data structure
+ stores a huge amount of metadata. Each node must contain,
+ besides a value, three pointers and a boolean. This type might
+ be avoided if space is at a premium [austern00noset].
+
High-probability balanced node-based trees suffer the
+ drawbacks of deterministic balanced trees. Although they are
+ fascinating data structures, preliminary tests with them showed
+ their performance was worse than red-black trees. The library
+ does not contain any such trees, therefore.
+
Competitive node-based trees have two drawbacks. They are
+ usually somewhat unbalanced, and they perform a large number of
+ comparisons. Balanced trees perform one comparison per each
+ node they encounter on a search path; a splay tree performs two
+ comparisons. If the keys are complex objects, e.g.,
+ std::string, this can increase the running time.
+ Conversely, such trees do well when there is much locality of
+ reference. It is difficult to determine in which case to prefer
+ such trees over balanced trees. This library includes a splay
+ tree (see Design::Associative
+ Containers::Tree-Based Containers).
Large-fan-out PATRICIA tries (see Design::Associative
+ Containers::Trie-Based Containers) have excellent lookup
+ performance, but they do so through maintaining, for each node,
+ a miniature "hash-table". Their space efficiency is low, and
+ their modification performance is bad. These tries might be
+ used for semi-static settings, where order preservation is
+ important. Alternatively, red-black trees cross-referenced with
+ hash tables can be used. [okasaki98mereable]
+ discusses small-fan-out PATRICIA tries for integers, but the
+ cited results seem to indicate that the amortized cost of
+ maintaining such trees is higher than that of balanced trees.
+ Moderate-fan-out trees might be useful for sequences where each
+ element has a limited number of choices, e.g., DNA
+ strings (see Examples::Associative
+ Containers::Trie-Based Containers).
Use a unique-key value associative container that maps
+ each primary key to some simple associative container of
+ secondary keys, say a list-based container (see Design::Associative
+ Containers::List-Based Containers)
+
Use a unique-key value associative container that maps
+ each primary key to some non-associative container
+ (e.g., std::vector)
+
Use a unique-key value associative container that takes
+ into account both primary and secondary keys.
+
+
We do not think there is a simple answer for this (excluding
+ option 1, which we think should be avoided in all cases).
+
If the expected ratio of secondary keys to primary keys is
+ small, then 3 and 4 seem reasonable. Both types of secondary
+ containers are relatively lightweight (in terms of memory use
+ and construction time), and so creating an entire container
+ object for each primary key is not too expensive. Option 4
+ might be preferable to option 3 if changing the secondary key
+ of some primary key is frequent - one cannot modify an
+ associative container's key, and the only possibility,
+ therefore, is erasing the secondary key and inserting another
+ one instead; a non-associative container, conversely, can
+ support in-place modification. The actual cost of erasing a
+ secondary key and inserting another one depends also on the
+ allocator used for secondary associative-containers (The tests
+ above used the standard allocator, but in practice one might
+ choose to use, e.g., [boost_pool]). Option 2 is
+ definitely an overkill in this case. Option 1 loses out either
+ immediately (when there is one secondary key per primary key)
+ or almost immediately after that. Option 5 has the same
+ drawbacks as option 2, but it has the additional drawback that
+ finding all values whose primary key is equivalent to some key,
+ might be linear in the total number of values stored (for
+ example, if using a hash-based container).
+
If the expected ratio of secondary keys to primary keys is
+ large, then the answer is more complicated. It depends on the
+ distribution of secondary keys to primary keys, the
+ distribution of accesses according to primary keys, and the
+ types of operations most frequent.
+
To be more precise, assume there are m primary keys,
+ primary key i is mapped to ni
+ secondary keys, and each primary key is mapped, on average, to
+ n secondary keys (i.e.,
+ E(ni) = n).
+
Suppose one wants to find a specific pair of primary and
+ secondary keys. Using 1 with a tree based container
+ (std::multimap), the expected cost is
+ E(Θ(log(m) + ni)) = Θ(log(m) +
+ n); using 1 with a hash-based container
+ (std::tr1::unordered_multimap), the expected cost is
+ Θ(n). Using 2 with a primary hash-based container
+ and secondary hash-based containers, the expected cost is
+ O(1); using 2 with a primary tree-based container and
+ secondary tree-based containers, the expected cost is (using
+ the Jensen inequality [motwani95random])
+ E(O(log(m) + log(ni)) = O(log(m)) +
+ E(O(log(ni)) = O(log(m)) + O(log(n)),
+ assuming that primary keys are accessed equiprobably. 3 and 4
+ are similar to 1, but with lower constants. Using 5 with a
+ hash-based container, the expected cost is O(1); using 5
+ with a tree based container, the cost is
+ E(Θ(log(mn))) = Θ(log(m) +
+ log(n)).
+
Suppose one needs the values whose primary key matches some
+ given key. Using 1 with a hash-based container, the expected
+ cost is Θ(n), but the values will not be ordered
+ by secondary keys (which may or may not be required); using 1
+ with a tree-based container, the expected cost is
+ Θ(log(m) + n), but with high constants; again the
+ values will not be ordered by secondary keys. 2, 3, and 4 are
+ similar to 1, but typically with lower constants (and,
+ additionally, if one uses a tree-based container for secondary
+ keys, they will be ordered). Using 5 with a hash-based
+ container, the cost is Θ(mn).
+
Suppose one wants to assign to a primary key all secondary
+ keys assigned to a different primary key. Using 1 with a
+ hash-based container, the expected cost is Θ(n),
+ but with very high constants; using 1 with a tree-based
+ container, the cost is Θ(nlog(mn)). Using 2, 3,
+ and 4, the expected cost is Θ(n), but typically
+ with far lower costs than 1. 5 is similar to 1.
The library contains a single comprehensive regression test.
+ For a given container type in pb_ds, the test creates
+ an object of the container type and an object of the
+ corresponding STL type (e.g., std::set). It
+ then performs a random sequence of methods with random
+ arguments (e.g., inserts, erases, and so forth) on both
+ objects. At each operation, the test checks the return value of
+ the method, and optionally both compares pb_ds's
+ object with the STL's object as well as performing other
+ consistency checks on pb_ds's object (e.g.,
+ order preservation, when applicable, or node invariants, when
+ applicable).
+
+
Additionally, the test integrally checks exception safety
+ and resource leaks. This is done as follows. A special
+ allocator type, written for the purpose of the test, both
+ randomly throws an exceptions when allocations are performed,
+ and tracks allocations and de-allocations. The exceptions thrown
+ at allocations simulate memory-allocation failures; the
+ tracking mechanism checks for memory-related bugs (e.g.,
+ resource leaks and multiple de-allocations). Both
+ pb_ds's containers and the containers' value-types are
+ configured to use this allocator.
+
+
Due to compiler constraints, the test is split into the
+ several sources, each checking only some containers.
Signifies a basic invalidation guarantee that any iterator,
+ pointer, or reference to a container object's mapped value type
+ is valid as long as the container is not modified.
Joins two trees. When this function returns,
+ other will be
+ empty.
+
+
When calling this method, other's keys must be all larger or
+ all smaller than this object's keys, and other's policies must be
+ equivalent to this object's policies.
Specifies whether the load factor can be accessed
+ externally. The two options have different trade-offs in
+ terms of flexibility, genericity, and encapsulation.
It is the responsibility of the user to pass an
+ appropriate load to this
+ function. Calling this method will not compile when
+ External_Load_Access
+ == false.
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, and r_eq_fn will be copied by the
+ eq_fn object of the
+ container object.
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, and r_comb_hash_fn will be copied by the
+ comb_hash_fn
+ object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, r_comb_hash_fn will be copied by the
+ comb_hash_fn
+ object of the container object, and r_resize_policy will be copied by
+ the resize_policy
+ object of the container object.
+
+
+
+
+
+
+template<
+ class It>
+ cc_hash_table
+ (It first_it,
+ It last_it)
+
+
+
+
+
Constructor taking iterators to a range of
+ value_types. The value_types between first_it and last_it will be inserted into the
+ container object.
+
+
+
+
+
+
+template<
+ class It>
+ cc_hash_table
+ (It first_it,
+ It last_it,
+ consthash_fn &r_hash_fn)
+
+
+
+
+
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object.
+
+
+
+
+
+
+template<
+ class It>
+ cc_hash_table
+ (It first_it,
+ It last_it,
+ consthash_fn &r_hash_fn,
+ consteq_fn &r_eq_fn)
+
+
+
+
+
Constructor taking iterators to a range of value_types
+ and some policy objects The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, and r_eq_fn will be copied by the
+ eq_fn object of the
+ container object.
Constructor taking iterators to a range of value_types
+ and some policy objects The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, and r_comb_hash_fn will be copied by the
+ comb_hash_fn
+ object of the container object.
Constructor taking iterators to a range of value_types
+ and some policy objects The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, r_comb_hash_fn will be copied by the
+ comb_hash_fn
+ object of the container object, and r_resize_policy will be copied by
+ the resize_policy
+ object of the container object.
A point-type iterator is an iterator that refers to a
+ specific element, e.g. as returned through an
+ associative-container's find method; a range-type
+ iterator is an iterator that is used to go over a sequence of
+ elements, e.g., as returned by a container's
+ find method. A point-type method is a method that
+ returns a point-type iterator; a range-type method is a method
+ that returns a range-type iterator.
+
+
For most containers, these types are synonymous; for
+ self-organizing containers, such as hash-based containers or
+ priority queues, these are inherently different (in any
+ implementation, including that of the STL), but in
+ pb_ds this is made explicit - they are distinct
+ types.
If one manipulates a container object, then iterators
+ previously obtained from it can be invalidated. In some cases a
+ previously-obtained iterator cannot be de-referenced; in other
+ cases, the iterator's next or previous element might have
+ changed unpredictably. This corresponds exactly to the question
+ whether a point-type or range-type iterator (see previous
+ concept) is valid or not. In pb_ds one can query a
+ container (in compile time) what are its invalidation
+ guarantees.
In pb_ds there are no associative containers which
+ allow multiple values with equivalent keys (such as the STL's
+ std::multimap, for example). Instead, one maps the
+ unique part of a key - the primary key, into an
+ associative-container of the (originally) non-unique parts of
+ the key - the secondary key. A primary associative-container is
+ an associative container of primary keys; a secondary
+ associative-container is an associative container of secondary
+ keys.
Associative containers are typically parametrized by
+ various policies. For example, a hash-based associative
+ container is parametrized by a hash-functor, transforming each
+ key into an non-negative numerical type. Each such value is
+ then further mapped into a position within the table. The
+ mapping of a key into a position within the table is therefore
+ a two-step process.
+
+
In some cases, instantiations are redundant. For
+ example, when the keys are integers, it is possible to use a
+ redundant hash policy, which transforms each key into
+ its value.
+
+
In some other cases, these policies are irrelevant.
+ For example, a hash-based associative container might transform
+ keys into positions within a table by a different method than
+ the two-step method described above. In such a case, the hash
+ functor is simply irrelevant.
+
+
pb_ds uses special pre-defined "null policies"
+ classes for these cases. Some null policies in pb_ds
+ are:
Inserts a value_type object. If
+ no value_type
+ with r_val's key was in
+ the container object, inserts and returns (point_iterator
+ object associated with r_val, true);
+ otherwise just returns (point_iterator
+ object associated with r_val's key,
+ false).
Erases any value_type satisfying
+ the predicate prd (this
+ is transactional, either all matching value_types are
+ erased, or, if an exception is thrown (for types whose
+ erase can throw an exception) none); returns the number
+ of value_types
+ erased.
Permission to use, copy, modify, sell, and distribute this
+ software is hereby granted without fee, provided that the above
+ copyright notice appears in all copies, and that both that
+ copyright notice and this permission notice appear in
+ supporting documentation.
+
+
None of the above authors, nor IBM Haifa Research
+ Laboratories, Red Hat, or both, make any representation about
+ the suitability of this software for any purpose. It is
+ provided "as is" without express or implied warranty.
The design attempts to address the following problem. When
+ writing a function manipulating a generic container object,
+ what is the behavior of the object? E.g., suppose one
+ writes
then one needs to address the following questions in the body
+of some_op_sequence:
+
+
+
Which types and methods does Cntnr support?
+ Containers based on hash tables can be queries for the
+ hash-functor type and object; this is meaningless for
+ tree-based containers. Containers based on trees can be
+ split, joined, or can erase iterators and return the
+ following iterator; this cannot be done by hash-based
+ containers.
+
+
What are the guarantees of Cntnr? A container
+ based on a probing hash-table invalidates all iterators when
+ it is modified; this is not the case for containers based on
+ node-based trees. Containers based on a node-based tree can
+ be split or joined without exceptions; this is not the case
+ for containers based on vector-based trees.
+
+
How does the container maintain its elements? Tree-based
+ and Trie-based containers store elements by key order;
+ others, typically, do not. A container based on a splay trees
+ or lists with update policies "cache" "frequently accessed"
+ elements; containers based on most other underlying
+ data structures do not.
+
+
+
The remainder of this section deals with these issues.
The hierarchy is composed naturally so that commonality is
+ captured by base classes. Thus operator[] is
+ defined container_base, since
+ all containers support it. Conversely split is defined
+ in basic_tree,
+ since only tree-like containers support it. Data-Structure Tags and Traits discusses how
+ to query which types and methods each container supports.
Tags and traits are very useful for manipulating generic
+ types. For example, if It is an iterator class, then
+ typename It::iterator_category or
+ typename
+ std::iterator_traits<It>::iterator_category will
+ yield its category, and typename
+ std::iterator_traits<It>::value_type will yield its
+ value type.
container_base
+ publicly defines container_category as one of the classes in
+ Figure Data-structure tag class
+ hierarchy. Given any container Cntnr, the tag of
+ the underlying data structure can be found via
+ typename Cntnr::container_category.
+
+
Additionally, a traits mechanism can be used to query a
+ container type for its attributes. Given any container
+ Cntnr, then pb_ds::container_traits<Cntnr>
+ is a traits class identifying the properties of the
+ container.
+
+
To find if a container can throw when a key is erased (which
+ is true for vector-based trees, for example), one can
+ use
Some of the definitions in container_traits are
+ dependent on other definitions. E.g., if container_traits<Cntnr>::order_preserving
+ is true (which is the case for containers based
+ on trees and tries), then the container can be split or joined;
+ in this case, container_traits<Cntnr>::split_join_can_throw
+ indicates whether splits or joins can throw exceptions (which
+ is true for vector-based trees); otherwise container_traits<Cntnr>::split_join_can_throw
+ will yield a compilation error. (This is somewhat similar to a
+ compile-time version of the COM model [mscom]).
The relationship between these iterator types varies between
+ container types. Figure Point-type and range-type iterators-A
+ shows the most general invariant between point-type and
+ range-type iterators: iterator, e.g., can
+ always be converted to point_iterator. Figure Point-type and range-type iterators-B
+ shows invariants for order-preserving containers: point-type
+ iterators are synonymous with range-type iterators.
+ Orthogonally, Figure Point-type
+ and range-type iterators-C shows invariants for "set"
+ containers: iterators are synonymous with const iterators.
+
+
+
+
Point-type and range-type iterators.
+
+
Note that point-type iterators in self-organizing containers
+ (e.g., hash-based associative containers) lack movement
+ operators, such as operator++ - in fact, this
+ is the reason why pb_ds differentiates from the STL's
+ design on this point.
+
+
Typically, one can determine an iterator's movement
+ capabilities in the STL using
+ std::iterator_traits<It>iterator_category, which
+ is a struct indicating the iterator's movement
+ capabilities. Unfortunately, none of the STL's predefined
+ categories reflect a pointer's not having any movement
+ capabilities whatsoever. Consequently, pb_ds adds a
+ type trivial_iterator_tag
+ (whose name is taken from a concept in [sgi_stl]), which is the category
+ of iterators with no movement capabilities. All other STL tags,
+ such as forward_iterator_tag retain their common
+ use.
Motivation::Associative
+ Containers::Differentiating between Iterator
+ Types::Invalidation Guarantees posed a problem. Given three
+ different types of associative containers, a modifying
+ operation (in that example, erase) invalidated
+ iterators in three different ways: the iterator of one
+ container remained completely valid - it could be de-referenced
+ and incremented; the iterator of a different container could
+ not even be de-referenced; the iterator of the third container
+ could be de-referenced, but its "next" iterator changed
+ unpredictably.
+
+
Distinguishing between find and range types allows
+ fine-grained invalidation guarantees, because these questions
+ correspond exactly to the question of whether point-type
+ iterators and range-type iterators are valid. Invalidation guarantees class
+ hierarchy shows tags corresponding to different types of
+ invalidation guarantees.
+
+
+
+
Invalidation guarantees class hierarchy.
+
+
+
basic_invalidation_guarantee
+ corresponds to a basic guarantee that a point-type iterator,
+ a found pointer, or a found reference, remains valid as long
+ as the container object is not modified.
+
+
point_invalidation_guarantee
+ corresponds to a guarantee that a point-type iterator, a
+ found pointer, or a found reference, remains valid even if
+ the container object is modified.
+
+
range_invalidation_guarantee
+ corresponds to a guarantee that a range-type iterator remains
+ valid even if the container object is modified.
Note that this hierarchy corresponds to the logic it
+ represents: if a container has range-invalidation guarantees,
+ then it must also have find invalidation guarantees;
+ correspondingly, its invalidation guarantee (in this case
+ range_invalidation_guarantee)
+ can be cast to its base class (in this case point_invalidation_guarantee).
+ This means that this this hierarchy can be used easily using
+ standard metaprogramming techniques, by specializing on the
+ type of invalidation_guarantee.
+
+
(These types of problems were addressed, in a more general
+ setting, in [meyers96more] - Item 2. In
+ our opinion, an invalidation-guarantee hierarchy would solve
+ these problems in all container types - not just associative
+ containers.)
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_1.png b/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_1.png
new file mode 100644
index 00000000000..9470a65b568
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_1.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_2.png b/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_2.png
new file mode 100644
index 00000000000..d2ac91c1ab0
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_2.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_3.png b/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_3.png
new file mode 100644
index 00000000000..08ecb0ffe16
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/embedded_lists_3.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/examples.html b/libstdc++-v3/docs/html/ext/pb_ds/examples.html
new file mode 100644
index 00000000000..03c7a391003
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/examples.html
@@ -0,0 +1,24 @@
+
+
+
+
+
+
+ Examples
+
+
+
+
+
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, and r_eq_fn will be copied by the
+ eq_fn object of the
+ container object.
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, and r_comb_probe_fn will be copied by
+ the comb_probe_fn
+ object of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, r_comb_probe_fn will be copied by
+ the comb_probe_fn
+ object of the container object, and r_probe_fn will be copied by the
+ probe_fn object
+ of the container object.
Constructor taking some policy objects. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, r_comb_probe_fn will be copied by
+ the comb_probe_fn
+ object of the container object, r_probe_fn will be copied by the
+ probe_fn object
+ of the container object, and r_resize_policy will be copied by
+ the Resize_Policy
+ object of the container object.
+
+
+
+
+
+
+template<
+ class It>
+ gp_hash_table
+ (It first_it,
+ It last_it)
+
+
+
+
+
Constructor taking iterators to a range of
+ value_types. The value_types between first_it and last_it will be inserted into the
+ container object.
+
+
+
+
+
+
+template<
+ class It>
+ gp_hash_table
+ (It first_it,
+ It last_it,
+ consthash_fn &r_hash_fn)
+
+
+
+
+
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object.
+
+
+
+
+
+
+template<
+ class It>
+ gp_hash_table
+ (It first_it,
+ It last_it,
+ consthash_fn &r_hash_fn,
+ consteq_fn &r_eq_fn)
+
+
+
+
+
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, and r_eq_fn will be copied by the
+ eq_fn object of the
+ container object.
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, and r_comb_probe_fn will be copied by
+ the comb_probe_fn
+ object of the container object.
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, r_comb_probe_fn will be copied by
+ the comb_probe_fn
+ object of the container object, and r_probe_fn will be copied by the
+ probe_fn object
+ of the container object.
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_hash_fn will be copied by the
+ hash_fn object of
+ the container object, r_eq_fn will be copied by the
+ eq_fn object of the
+ container object, r_comb_probe_fn will be copied by
+ the comb_probe_fn
+ object of the container object, r_probe_fn will be copied by the
+ probe_fn object
+ of the container object, and r_resize_policy will be copied by
+ the resize_policy
+ object of the container object.
Comb_Hash_Fn is a range-hashing_functor;
+ it describes how to translate hash values into positions
+ within the table. This is described in Hash Policies.
+
+
Resize_Policy describes how a container object
+ should change its internal size. This is described in
+ Resize Policies.
+
+
Store_Hash indicates whether the hash value
+ should be stored with each entry. This is described in
+ Policy Interaction.
+
+
Allocator is an allocator
+ type.
+
+
+
The probing hash-based container has the following
+ declaration.
Hash functions, ranged-hash functions, and
+ range-hashing functions.
+
+
Let U be a domain (e.g., the integers, or the
+ strings of 3 characters). A hash-table algorithm needs to map
+ elements of U "uniformly" into the range [0,..., m -
+ 1] (where m is a non-negative integral value, and
+ is, in general, time varying). I.e., the algorithm needs
+ a ranged-hash function
+
+
f : U × Z+ → Z+
+ ,
+
+
such that for any u in U ,
+
+
0 ≤ f(u, m) ≤ m - 1 ,
+
+
and which has "good uniformity" properties [knuth98sorting]. One
+ common solution is to use the composition of the hash
+ function
+
+
h : U → Z+ ,
+
+
which maps elements of U into the non-negative
+ integrals, and
+
+
g : Z+ × Z+ →
+ Z+,
+
+
which maps a non-negative hash value, and a non-negative
+ range upper-bound into a non-negative integral in the range
+ between 0 (inclusive) and the range upper bound (exclusive),
+ i.e., for any r in Z+,
From the above, it is obvious that given g and
+ h, f can always be composed (however the converse
+ is not true). The STL's hash-based containers allow specifying
+ a hash function, and use a hard-wired range-hashing function;
+ the ranged-hash function is implicitly composed.
+
+
The above describes the case where a key is to be mapped
+ into a single position within a hash table, e.g.,
+ in a collision-chaining table. In other cases, a key is to be
+ mapped into a sequence of positions within a table,
+ e.g., in a probing table. Similar terms apply in this
+ case: the table requires a ranged probe function,
+ mapping a key into a sequence of positions withing the table.
+ This is typically achieved by composing a hash function
+ mapping the key into a non-negative integral type, a
+ probe function transforming the hash value into a
+ sequence of hash values, and a range-hashing function
+ transforming the sequence of hash values into a sequence of
+ positions.
respectively, for some positive integrals u and
+ v (typically powers of 2), and some a. Each of
+ these range-hashing functions works best for some different
+ setting.
+
+
The division method (2) is a
+ very common choice. However, even this single method can be
+ implemented in two very different ways. It is possible to
+ implement (2) using the low
+ level % (modulo) operation (for any m), or the
+ low level & (bit-mask) operation (for the case where
+ m is a power of 2), i.e.,
The % (modulo) implementation (3) has the advantage that for
+ m a prime far from a power of 2, g(r, m) is
+ affected by all the bits of r (minimizing the chance of
+ collision). It has the disadvantage of using the costly modulo
+ operation. This method is hard-wired into SGI's implementation
+ [sgi_stl].
+
+
The & (bit-mask) implementation (4) has the advantage of
+ relying on the fast bit-wise and operation. It has the
+ disadvantage that for g(r, m) is affected only by the
+ low order bits of r. This method is hard-wired into
+ Dinkumware's implementation [dinkumware_stl].
In cases it is beneficial to allow the
+ client to directly specify a ranged-hash hash function. It is
+ true, that the writer of the ranged-hash function cannot rely
+ on the values of m having specific numerical properties
+ suitable for hashing (in the sense used in [knuth98sorting]), since
+ the values of m are determined by a resize policy with
+ possibly orthogonal considerations.
+
+
There are two cases where a ranged-hash function can be
+ superior. The firs is when using perfect hashing [knuth98sorting]; the
+ second is when the values of m can be used to estimate
+ the "general" number of distinct values required. This is
+ described in the following.
+
+
Let
+
+
s = [ s0,..., st - 1]
+
+
be a string of t characters, each of which is from
+ domain S. Consider the following ranged-hash
+ function:
where a is some non-negative integral value. This is
+ the standard string-hashing function used in SGI's
+ implementation (with a = 5) [sgi_stl]. Its advantage is that
+ it takes into account all of the characters of the string.
+
+
Now assume that s is the string representation of a
+ of a long DNA sequence (and so S = {'A', 'C', 'G',
+ 'T'}). In this case, scanning the entire string might be
+ prohibitively expensive. A possible alternative might be to use
+ only the first k characters of the string, where
Other more elaborate hash-functions might scan k
+ characters starting at a random position (determined at each
+ resize), or scanning k random positions (determined at
+ each resize), i.e., using
+
+
f3(s, m) = ∑ i =
+ r0r0 + k - 1 si
+ ai mod m ,
+
+
or
+
+
f4(s, m) = ∑ i = 0k -
+ 1 sri ari mod
+ m ,
+
+
respectively, for r0,..., rk-1
+ each in the (inclusive) range [0,...,t-1].
+
+
It should be noted that the above functions cannot be
+ decomposed as (1) .
This sub-subsection describes the implementation of the
+ above in pb_ds. It first explains range-hashing
+ functions in collision-chaining tables, then ranged-hash
+ functions in collision-chaining tables, then probing-based
+ tables, and, finally, lists the relevant classes in
+ pb_ds.
+
+
Range-Hashing and Ranged-Hashes in Collision-Chaining
+ Tables
+
+
cc_hash_table is
+ parametrized by Hash_Fn and Comb_Hash_Fn, a
+ hash functor and a combining hash functor, respectively.
+
+
In general, Comb_Hash_Fn is considered a
+ range-hashing functor. cc_hash_table
+ synthesizes a ranged-hash function from Hash_Fn and
+ Comb_Hash_Fn (see (1)
+ above). Figure Insert
+ hash sequence diagram shows an insert sequence
+ diagram for this case. The user inserts an element (point A),
+ the container transforms the key into a non-negative integral
+ using the hash functor (points B and C), and transforms the
+ result into a position using the combining functor (points D
+ and E).
Insert hash sequence diagram with a null hash
+ policy.
+
+
Probing Tables
+
+
gp_hash_table is
+ parametrized by Hash_Fn, Probe_Fn, and
+ Comb_Probe_Fn. As before, if Probe_Fn and
+ Comb_Probe_Fn are, respectively, null_hash_fn and null_probe_fn, then
+ Comb_Probe_Fn is a ranged-probe functor. Otherwise,
+ Hash_Fn is a hash functor, Probe_Fn is a
+ functor for offsets from a hash value, and
+ Comb_Probe_Fn transforms a probe sequence into a
+ sequence of positions within the table.
+
+
Pre-Defined Policies
+
+
pb_ds contains some pre-defined classes
+ implementing range-hashing and probing functions:
Hash-tables, as opposed to trees, do not naturally grow or
+ shrink. It is necessary to specify policies to determine how
+ and when a hash table should change its size. Usually, resize
+ policies can be decomposed into orthogonal policies:
+
+
+
A size policy indicating how a hash table
+ should grow (e.g., it should multiply by powers of
+ 2).
+
+
A trigger policy indicating when a hash
+ table should grow (e.g., a load factor is
+ exceeded).
Size policies determine how a hash table changes size. These
+ policies are simple, and there are relatively few sensible
+ options. An exponential-size policy (with the initial size and
+ growth factors both powers of 2) works well with a mask-based
+ range-hashing function (see Range-Hashing Policies), and is the
+ hard-wired policy used by Dinkumware [dinkumware_stl]. A
+ prime-list based policy works well with a modulo-prime range
+ hashing function (see Range-Hashing
+ Policies), and is the hard-wired policy used by SGI's
+ implementation [sgi_stl].
Trigger policies determine when a hash table changes size.
+ Following is a description of two policies: load-check
+ policies, and collision-check policies.
+
+
Load-check policies are straightforward. The user specifies
+ two factors, αmin and
+ αmax, and the hash table maintains the
+ invariant that
Collision-check policies work in the opposite direction of
+ load-check policies. They focus on keeping the number of
+ collisions moderate and hoping that the size of the table will
+ not grow very large, instead of keeping a moderate load-factor
+ and hoping that the number of collisions will be small. A
+ maximal collision-check policy resizes when the longest
+ probe-sequence grows too large.
+
+
Consider Figure Balls and
+ bins. Let the size of the hash table be denoted by
+ m, the length of a probe sequence be denoted by
+ k, and some load factor be denoted by α. We would
+ like to calculate the minimal length of k, such that if
+ there were α m elements in the hash table, a probe
+ sequence of length k would be found with probability at
+ most 1/m.
+
+
+
+
Balls and bins.
+
+
Denote the probability that a probe sequence of length
+ k appears in bin i by pi, the
+ length of the probe sequence of bin i by
+ li, and assume uniform distribution. Then
where (a) follows from the Chernoff bound [motwani95random]. To
+ calculate the probability that some bin contains a probe
+ sequence greater than k, we note that the
+ li are negatively-dependent [dubhashi98neg]. Let
+ I(.) denote the indicator function. Then
P ( ∑ i = 1mI (
+ li ≥ k ) ≥ m p1 ( 1 + 1 / (m
+ p1) - 1 ) ) ≤ (a)
+
+
e ^ ( ( - m p1 ( 1 / (m p1)
+ - 1 ) 2 ) / 2 ) ,
+
+
where (a) follows from the fact that the Chernoff bound can
+ be applied to negatively-dependent variables [dubhashi98neg]. Inserting
+ (2) into (3), and equating with
+ 1/m, we obtain
This sub-subsection describes the implementation of the
+ above in pb_ds. It first describes resize policies and
+ their decomposition into trigger and size policies, then
+ describes pre-defined classes, and finally discusses controlled
+ access the policies' internals.
+
+
Resize Policies and Their Decomposition
+
+
Each hash-based container is parametrized by a
+ Resize_Policy parameter; the container derives
+ publicly from Resize_Policy. For
+ example:
As a container object is modified, it continuously notifies
+ its Resize_Policy base of internal changes
+ (e.g., collisions encountered and elements being
+ inserted). It queries its Resize_Policy base whether
+ it needs to be resized, and if so, to what size.
+
+
Figure Insert
+ resize sequence diagram shows a (possible) sequence diagram
+ of an insert operation. The user inserts an element; the hash
+ table notifies its resize policy that a search has started
+ (point A); in this case, a single collision is encountered -
+ the table notifies its resize policy of this (point B); the
+ container finally notifies its resize policy that the search
+ has ended (point C); it then queries its resize policy whether
+ a resize is needed, and if so, what is the new size (points D
+ to G); following the resize, it notifies the policy that a
+ resize has completed (point H); finally, the element is
+ inserted, and the policy notified (point I).
+
+
+
+
Insert resize sequence diagram.
+
+
In practice, a resize policy can be usually orthogonally
+ decomposed to a size policy and a trigger policy. Consequently,
+ the library contains a single class for instantiating a resize
+ policy: hash_standard_resize_policy
+ is parametrized by Size_Policy and
+ Trigger_Policy, derives publicly from
+ both, and acts as a standard delegate [gamma95designpatterns]
+ to these policies.
There are cases where (controlled) access to resize
+ policies' internals is beneficial. E.g., it is sometimes
+ useful to query a hash-table for the table's actual size (as
+ opposed to its size() - the number of values it
+ currently holds); it is sometimes useful to set a table's
+ initial size, externally resize it, or change load factors.
+
+
Clearly, supporting such methods both decreases the
+ encapsulation of hash-based containers, and increases the
+ diversity between different associative-containers' interfaces.
+ Conversely, omitting such methods can decrease containers'
+ flexibility.
+
+
In order to avoid, to the extent possible, the above
+ conflict, the hash-based containers themselves do not address
+ any of these questions; this is deferred to the resize policies,
+ which are easier to change or replace. Thus, for example,
+ neither cc_hash_table nor
+ gp_hash_table
+ contain methods for querying the actual size of the table; this
+ is deferred to hash_standard_resize_policy.
+
+
Furthermore, the policies themselves are parametrized by
+ template arguments that determine the methods they support
+ ([alexandrescu01modern]
+ shows techniques for doing so). hash_standard_resize_policy
+ is parametrized by External_Size_Access that
+ determines whether it supports methods for querying the actual
+ size of the table or resizing it. hash_load_check_resize_trigger
+ is parametrized by External_Load_Access that
+ determines whether it supports methods for querying or
+ modifying the loads. cc_hash_max_collision_check_resize_trigger
+ is parametrized by External_Load_Access that
+ determines whether it supports methods for querying the
+ load.
+
+
Some operations, for example, resizing a container at
+ run time, or changing the load factors of a load-check trigger
+ policy, require the container itself to resize. As mentioned
+ above, the hash-based containers themselves do not contain
+ these types of methods, only their resize policies.
+ Consequently, there must be some mechanism for a resize policy
+ to manipulate the hash-based container. As the hash-based
+ container is a subclass of the resize policy, this is done
+ through virtual methods. Each hash-based container has a
+ privatevirtual method:
which resizes the container. Implementations of
+ Resize_Policy can export public methods for resizing
+ the container externally; these methods internally call
+ do_resize to resize the table.
Hash-tables are unfortunately especially susceptible to
+ choice of policies. One of the more complicated aspects of this
+ is that poor combinations of good policies can form a poor
+ container. Following are some considerations.
Some combinations do not work well for probing containers.
+ For example, combining a quadratic probe policy with an
+ exponential size policy can yield a poor container: when an
+ element is inserted, a trigger policy might decide that there
+ is no need to resize, as the table still contains unused
+ entries; the probe sequence, however, might never reach any of
+ the unused entries.
+
+
Unfortunately, pb_ds cannot detect such problems at
+ compilation (they are halting reducible). It therefore defines
+ an exception class insert_error to throw an
+ exception in this case.
Some trigger policies are especially susceptible to poor
+ hash functions. Suppose, as an extreme case, that the hash
+ function transforms each key to the same hash value. After some
+ inserts, a collision detecting policy will always indicate that
+ the container needs to grow.
+
+
The library, therefore, by design, limits each operation to
+ one resize. For each insert, for example, it queries
+ only once whether a resize is needed.
cc_hash_table and
+ gp_hash_table are
+ parametrized by an equivalence functor and by a
+ Store_Hash parameter. If the latter parameter is
+ true, then the container stores with each entry
+ a hash value, and uses this value in case of collisions to
+ determine whether to apply a hash value. This can lower the
+ cost of collision for some types, but increase the cost of
+ collisions for other types.
+
+
If a ranged-hash function or ranged probe function is
+ directly supplied, however, then it makes no sense to store the
+ hash value with each entry. pb_ds's container will
+ fail at compilation, by design, if this is attempted.
Assume a size policy issues an increasing sequence of sizes
+ a, a q, a q1, a q2, ... For
+ example, an exponential size policy might issue the sequence of
+ sizes 8, 16, 32, 64, ...
+
+
If a load-check trigger policy is used, with loads
+ αmin and αmax,
+ respectively, then it is a good idea to have:
+
+
+
αmax ~ 1 / q
+
+
αmin < 1 / (2 q)
+
+
+
This will ensure that the amortized hash cost of each
+ modifying operation is at most approximately 3.
+
+
αmin ~ αmax is, in
+ any case, a bad choice, and αmin >
+ αmax is horrendous.
Default constructor, or constructor taking a
+ start_size, or
+ constructor taking a start size and grow_factor. The policy will use the
+ sequence of sizes start_size, start_size * grow_factor, start_size * grow_factor^2, ...
Specifies whether the load factor can be accessed
+ externally. The two options have different trade-offs in
+ terms of flexibility, genericity, and encapsulation.
Sets the loads through a pair of the minimal and
+ maximal loads, respectively.
+
+
Calling this method resizes the container, and might
+ throw an exception. It is the responsibility of the user
+ to pass appropriate loads to this function. Calling this
+ method will not compile when External_Load_Access
+ == false.
This method is called only if this object indicated
+ resize is needed. The actual size of the table is size, and the number of entries in
+ it is num_entries.
Default constructor, or constructor taking a
+ start_size The policy
+ will use the sequence of sizes approximately start_size, start_size * 2, start_size * 2^2, ...
This test inserts a number of uniform i.i.d. integer keys
+ into a container, then erases all keys except one. It measures
+ the final size of the container.
STL hash-based containers act very differently than trees in
+ this respect. When erasing numerous keys from an STL
+ associative-container, the resulting memory user varies greatly
+ depending on whether the container is tree-based or hash-based.
+ As noted in Motivation::Choice of
+ Methods , this is a fundamental consequence of the STL's
+ associative containers' interface, it is not due to a specific
+ implementation.
This test inserts a number of values with uniform i.i.d.
+ integer keys into a container, then performs a series of finds
+ using find. It measures the average time
+ forfind as a function of the number of values
+ inserted.
Figures NCCG, NCCM,
+ and NCCL show the results for the native
+ and collision-chaining types in g++, MSVC++, and
+ local,
+ respectively; Figures NGPG, NGPM, and NGPL show the results
+ for the native and probing types in g++, MSVC++, and
+ local
+ respectively.
+
+
+
+
+
NCCG: Native and collision-chaining hash random int find timing test using find - g++
In the above figure, the names in the legends have the following meaning:
+
+
+n_hash_map_ncah-
+std::tr1::unordered_map with cache_hash_code = false
When comparing Figures NCCG and NCCM to NGPG and NGPM , respectively, it is apparent that the
+ probing containers are less efficient than the
+ collision-chaining containers (both
+ std::tr1::unordered_map and stdext::hash_map
+ use collision-chaining) in this case.
Within each type of hash-table, the range-hashing scheme
+ affects performance more than other policies; Hash-Based
+ Text find Find Timing Test::Observations discusses
+ this. In Figures NCCG , NCCM , NGPG , and NGPM , it should be noted that
+ std::tr1::unordered_map and stdext::hash_map
+ are hard-wired currently to mod-based and mask-based schemes,
+ respectively.
This test inserts a number of values with uniform i.i.d.
+ integer keys into a container, then performs a series of finds
+ using operator[]. It measures the average time
+ for operator[] as a function of the number of
+ values inserted.
Figures NCCG, NCCM,
+ and NCCL show the results for the native
+ and collision-chaining types in g++, MSVC++, and
+ local,
+ respectively; Figures NGPG, NGPM, and NGPL show the results
+ for the native and probing types in g++, MSVC++, and
+ local,
+ respectively.
+
+
+
+
+
NCCG: Native and collision-chaining hash random int find timing test using operator[] - g++
In the above figure, the names in the legends have the following meaning:
+
+
+n_hash_map_ncah-
+std::tr1::unordered_map with cache_hash_code = false
This test inserts a number of values with uniform i.i.d.
+ integer keys into a container, using
+ operator[]. It measures the average time for
+ operator[] as a function of the number of
+ values inserted.
Figures NCCG, NCCM,
+ and NCCL show the results for the native
+ and collision-chaining types in g++, MSVC++, and
+ local,
+ respectively; Figures NGPG, NGPM, and NGPL show the results
+ for the native and probing types in g++, msvc++, and
+ local
+ respectively; Figures CCGPG, CCGPM, and CCGPL compare the
+ results for the collision-chaining and probing types of
+ pb_ds only, in g++, MSVC++, and
+ local
+ respectively.
+
+
+
+
+
NCCG: Native and collision-chaining hash random int insert timing test using operator - g++
In the above figure, the names in the legends have the following meaning:
In this setting, probing tables function sometimes more
+ efficiently than collision-chaining tables (see Figures
+ CCGPG and CCGPM ).
+ This is explained shortly.
+
The performance graphs have a "saw-tooth" shape. The
+ average insert time rises and falls. As values are inserted
+ into the container, the load factor grows larger. Eventually,
+ a resize occurs. The reallocations and rehashing are
+ relatively expensive. After this, the load factor is smaller
+ than before.
+
+
Collision-chaining containers use indirection for greater
+ flexibility; probing containers store values contiguously, in
+ an array (see Figure Motivation::Different
+ underlying data structures A and B, respectively). It
+ follows that for simple data types, probing containers access
+ their allocator less frequently than collision-chaining
+ containers, (although they still have less efficient probing
+ sequences). This explains why some probing containers fare
+ better than collision-chaining containers in this case.
+
Within each type of hash-table, the range-hashing scheme
+ affects performance more than other policies. This is similar
+ to the situation in Hash-Based Text
+ find Find Timing Test and Hash-Based
+ Random-Integer find Find Timing Test.
+ Unsurprisingly, however, containers with lower
+alphamax perform worse in this case,
+ since more re-hashes are performed.
constructor taking some policies. r_size_policy will be copied by the
+ Size_Policy
+ object of this object. r_trigger_policy will be copied by
+ the Trigger_Policy
+ object of this object.
This method returns the number of entries (used and
+ unused) in the container. It is different from the
+ container's size method, which returns the number of used
+ entries. Calling this method will not compile when
+ External_Size_Access
+ == false.
Queries what the new size should be, when the container
+ is resized naturally. The current size of the container
+ is size, and the number
+ of used entries within the container is num_used_e.
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ a container, then performs a series of finds using
+ find . It measures the average time for find
+ as a function of the number of values inserted.
+
(The test was executed with text_find_timing_test
+ thirty_years_among_the_dead_preproc.txt 200 200 2100)
In this setting, the range-hashing scheme (See Design::Associative
+ Containers::Hash-Based Containers::Hash Policies ) affects
+ performance more than other policies. As Figure NCCG shows, containers using mod-based
+ range-hashing (including the native hash-based container, which
+ is currently hard-wired to this scheme) have lower performance
+ than those using mask-based range-hashing. A modulo-based
+ range-hashing scheme's main benefit is that it takes into
+ account all hash-value bits. Standard string hash-functions are
+ designed to create hash values that are nearly-uniform as is [
+ knuth98sorting
+ ].
Perhaps surprisingly, storing the hash value alongside each
+ entry affects performance only marginally, at least in
+ pb_ds 's implementation. (Unfortunately, it was not
+ possible to run the tests with std::tr1::unordered_map
+ 's cache_hash_code = true , as it appeared to
+ malfuntion.)
This test inserts a number of values with a markedly
+ non-uniform i.i.d. integer keys into a container, then performs
+ a series of finds using find . It measures the average
+ time for find as a function of the number of values in
+ the containers. The keys are generated as follows. First, a
+ uniform integer is created; it is then shifted left 8 bits.
The range-hashing scheme affects performance dramatically. A
+ mask-based range-hashing scheme effectively maps all values
+ into the same bucket. Access degenerates into a search within
+ an unordered linked-list. In Figures NHG and
+ NHM , it should be noted that
+ std::tr1::unordered_map and stdext::hash_map
+ are hard-wired currently to mod-based and mask-based schemes,
+ respectively.
+
When observing the settings of this test, it is apparent
+ that the keys' distribution is far from natural. One might ask
+ if the test is not contrived to show that, in some cases,
+ mod-based range hashing does better than mask-based range
+ hashing. This is, in fact just the case. We did not encounter a
+ more natural case in which mod-based range hashing is better.
+ In our opnion, real-life key distributions are handled better
+ with an appropriate hash function and a mask-based
+ range-hashing function. (shift_mask.cc
+ shows an example of handling this a-priori known skewed
+ distribution with a mask-based range-hashing function). If hash
+ performance is bad, a Χ2 test can be used
+ to check how to transform it into a more uniform
+ distribution.
+
For this reason, pb_ds's default range-hashing
+ function is mask-based.
This is a library of policy-based elementary
+ data structures: associative containers and priority queues. It
+ is designed for high-performance, flexibility, semantic safety,
+ and conformance to the corresponding containers in std
+ and std::tr1 (except for some points where it differs by
+ design).
An entry cannot be inserted into a container object for logical
+reasons (not, e.g., if memory is unavailable, in which case the
+allocator's exception will be thrown).
+
+
This exception may be thrown, e.g., when a probe sequence in
+ a probing hash table does not encounter any free positions,
+ even though free positions are available.
All code is enclosed in namespace pb_ds. Nested within
+ this is namespace detail, which contains the parts of this
+ library that are considered implementation details.
rc_binomial_heap_tag
+ - redundant-counter binomial-heap (i.e., a heap where
+ binomial trees form a sequence that is similar to a
+ de-amortized bit-addition algorithm) structure tag
+
+
binary_heap_tag -
+ binary heap (based on an array or an array of nodes)
+ structure tag
This section describes what problems the library attempts to
+ solve. Motivation describes the
+ reasons we think it solves these problems better than similar
+ libraries.
Associative containers depend on their policies to a very
+ large extent. Implicitly hard-wiring policies can hamper their
+ performance and limit their functionality. An efficient
+ hash-based container, for example, requires policies for
+ testing key equivalence, hashing keys, translating hash
+ values into positions within the hash table, and determining
+ when and how to resize the table internally. A tree-based
+ container can efficiently support order statistics,
+ i.e., the ability to query what is the order of each
+ key within the sequence of keys in the container, but only if
+ the container is supplied with a policy to internally update
+ meta-data. There are many other such examples.
+
+
Ideally, all associative containers would share the same
+ interface. Unfortunately, underlying data structures and
+ mapping semantics differentiate between different containers.
+ For example, suppose one writes a generic function
+ manipulating an associative container Cntnr:
+
+
+then what can one assume about Cntnr? The answer
+varies according to its underlying data structure. If the
+underlying data structure of Cntnr is based on a tree or
+trie, then the order of elements is well defined; otherwise, it is
+not, in general. If the underlying data structure of Cntnr
+is based on a collision-chaining hash table, then modifying
+r_Cntnr will not invalidate its iterators' order; if the
+underlying data structure is a probing hash table, then this is not
+the case. If the underlying data structure is based on a tree or
+trie, then r_cnt can efficiently be split; otherwise, it
+cannot, in general. If the underlying data structure is a red-black
+tree, then splitting r_cnt is exception-free; if it is an
+ordered-vector tree, exceptions can be thrown.
+
Priority queues are useful when one needs to efficiently
+ access a minimum (or maximum) value as the set of values
+ changes.
+
+
+
Most useful data structures for priority queues have a
+ relatively simple structure, as they are geared toward
+ relatively simple requirements. Unfortunately, these structures
+ do not support access to an arbitrary value, which turns out to
+ be necessary in many algorithms. Say, decreasing an arbitrary
+ value in a graph algorithm. Therefore, some extra mechanism is
+ necessary and must be invented for accessing arbitrary
+ values. There are at least two alternatives: embedding an
+ associative container in a priority queue, or allowing
+ cross-referencing through iterators. The first solution adds
+ significant overhead; the second solution requires a precise
+ definition of iterator invalidation. Which is the next
+ point...
+
+
Priority queues, like hash-based containers, store values in
+ an order that is meaningless and undefined externally. For
+ example, a push operation can internally reorganize the
+ values. Because of this characteristic, describing a priority
+ queues' iterator is difficult: on one hand, the values to which
+ iterators point can remain valid, but on the other, the logical
+ order of iterators can change unpredictably.
+
+
Roughly speaking, any element that is both inserted to a
+ priority queue (e.g., through push) and removed
+ from it (e.g., through pop), incurs a
+ logarithmic overhead (in the amortized sense). Different
+ underlying data structures place the actual cost differently:
+ some are optimized for amortized complexity, whereas others
+ guarantee that specific operations only have a constant
+ cost. One underlying data structure might be chosen if modifying
+ a value is frequent (Dijkstra's shortest-path algorithm),
+ whereas a different one might be chosen
+ otherwise. Unfortunately, an array-based binary heap - an
+ underlying data structure that optimizes (in the amortized
+ sense) push and pop operations, differs from
+ the others in terms of its invalidation guarantees. Other design
+ decisions also impact the cost and placement of the overhead, at
+ the expense of more difference in the the kinds of operations
+ that the underlying data structure can support. These
+ differences pose a challenge when creating a uniform interface
+ for priority queues.
+
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/invalidation_guarantee_cd.png b/libstdc++-v3/docs/html/ext/pb_ds/invalidation_guarantee_cd.png
new file mode 100644
index 00000000000..1f9d1243c6a
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/invalidation_guarantee_cd.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/invalidation_guarantee_erase.png b/libstdc++-v3/docs/html/ext/pb_ds/invalidation_guarantee_erase.png
new file mode 100644
index 00000000000..940a27f7142
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/invalidation_guarantee_erase.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/join_error.html b/libstdc++-v3/docs/html/ext/pb_ds/join_error.html
new file mode 100644
index 00000000000..3441e1fb20b
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/join_error.html
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+join_error Interface
+
+
+
+
+
+
join_error Interface
+
+
A join cannot be performed logical reasons (i.e., the ranges of the
+ two container objects
+ being joined
+ overlaps.
List-based containers might also be useful for some rare
+ cases, where a key is encapsulated to the extent that only
+ key-equivalence can be tested. Hash-based containers need to
+ know how to transform a key into a size type, and tree-based
+ containers need to know if some key is larger than another.
+ List-based associative containers, conversely, only need to
+ know if two keys are equivalent.
+
+
Since a list-based associative container does not order
+ elements by keys, is it possible to order the list in some
+ useful manner? Remarkably, many on-line competitive [motwani95random]
+ algorithms exist for reordering lists to reflect access
+ prediction [andrew04mtf].
Figure A simple list shows a
+ simple list of integer keys. If we search for the integer 6, we
+ are paying an overhead: the link with key 6 is only the fifth
+ link; if it were the first link, it could be accessed
+ faster.
+
+
+
+
A simple list.
+
+
List-update algorithms reorder lists as elements are
+ accessed. They try to determine, by the access history, which
+ keys to move to the front of the list. Some of these algorithms
+ require adding some metadata alongside each entry.
+
+
For example, Figure The counter algorithm
+ -A shows the counter algorithm. Each node contains both a key
+ and a count metadata (shown in bold). When an element is
+ accessed (e.g. 6) its count is incremented, as shown in
+ Figure The counter algorithm -B. If the count
+ reaches some predetermined value, say 10, as shown in Figure
+ The counter algorithm -C, the count is set to
+ 0 and the node is moved to the front of the list, as in Figure
+ The counter algorithm -D.
pb_ds allows instantiating lists with policies
+ implementing any algorithm moving nodes to the front of the
+ list (policies implementing algorithms interchanging nodes are
+ unsupported).
+
+
Associative containers based on lists are parametrized by a
+ Update_Policy parameter. This parameter defines the
+ type of metadata each node contains, how to create the
+ metadata, and how to decide, using this metadata, whether to
+ move a node to the front of the list. A list-based associative
+ container object derives (publicly) from its update policy.
+ Figure A list and its update
+ policy shows the scheme, as well as some predefined
+ policies (which are explained below).
+
+
+
+
A list and its update policy.
+
+
An instantiation of Update_Policy must define
+ internally update_metadata as the metadata it
+ requires. Internally, each node of the list contains, besides
+ the usual key and data, an instance of typename
+ Update_Policy::update_metadata.
+
+
An instantiation of Update_Policy must define
+ internally two operators:
The first is called by the container object, when creating a
+ new node, to create the node's metadata. The second is called
+ by the container object, when a node is accessed (e.g.,
+ when a find operation's key is equivalent to the key of the
+ node), to determine whether to move the node to the front of
+ the list.
+
+
The library contains two predefined implementations of
+ list-update policies [andrew04mtf]. The first is
+ counter_lu_policy, which
+ implements the counter algorithm described above. The second is
+ move_to_front_lu_policy,
+ which unconditionally move an accessed element to the front of
+ the list. The latter type is very useful in pb_ds,
+ since there is no need to associate metadata with each element
+ (this is explained further in Use for
+ "Multimaps").
List-based containers are especially useful as associative
+ containers for secondary keys. In fact, they are implemented
+ here expressly for this purpose.
+
+
To begin with, these containers use very little per-entry
+ structure memory overhead, since they can be implemented as
+ singly-linked lists. (Arrays use even lower per-entry memory
+ overhead, but they are less flexible in moving around entries,
+ and have weaker invalidation guarantees).
+
+
More importantly, though, list-based containers use very
+ little per-container memory overhead. The memory overhead of an
+ empty list-based container is practically that of a pointer.
+ This is important for when they are used as secondary
+ associative-containers in situations where the average ratio of
+ secondary keys to primary keys is low (or even 1).
+
+
In order to reduce the per-container memory overhead as much
+ as possible, they are implemented as closely as possible to
+ singly-linked lists.
+
+
+
List-based containers do not store internally the number
+ of values that they hold. This means that their size
+ method has linear complexity (just like std::list).
+ Note that finding the number of equivalent-key values in an
+ STL multimap also has linear complexity (because it must be
+ done, e.g., via std::distance of the
+ multimap's equal_range method), but usually with
+ higher constants.
+
+
Most associative-container objects each hold a policy
+ object (e.g., a hash-based container object holds a
+ hash functor). List-based containers, conversely, only have
+ class-wide policy objects.
Many fine associative-container libraries were already
+ written, most notably, the STL's associative containers. Why
+ then write another library? This section shows some possible
+ advantages of this library, when considering the challenges in
+ Introduction. Many of these
+ points stem from the fact that the STL introduced
+ associative-containers in a two-step process (first
+ standardizing tree-based containers, only then adding
+ hash-based containers, which are fundamentally different), did
+ not standardize priority queues as containers, and (in our
+ opinion) overloads the iterator concept.
Associative containers require a relatively large number of
+ policies to function efficiently in various settings. In some
+ cases this is needed for making their common operations more
+ efficient, and in other cases this allows them to support a
+ larger set of operations
+
+
+
Hash-based containers, for example, support look-up and
+ insertion methods (e.g., find and
+ insert). In order to locate elements quickly, they
+ are supplied a hash functor, which instruct how to transform
+ a key object into some size type; e.g., a hash functor
+ might transform "hello" into 1123002298. A
+ hash table, though, requires transforming each key object
+ into some size-type type in some specific domain;
+ e.g., a hash table with a 128-long table might
+ transform "hello" into position 63. The policy by
+ which the hash value is transformed into a position within
+ the table can dramatically affect performance (see Design::Associative
+ Containers::Hash-Based Containers::Hash Policies).
+ Hash-based containers also do not resize naturally (as
+ opposed to tree-based containers, for example). The
+ appropriate resize policy is unfortunately intertwined with
+ the policy that transforms hash value into a position within
+ the table (see Design::Associative
+ Containers::Hash-Based Containers::Resize Policies).
+
+
Tree-based containers, for example, also support look-up
+ and insertion methods, and are primarily useful when
+ maintaining order between elements is important. In some
+ cases, though, one can utilize their balancing algorithms for
+ completely different purposes.
+
+
Figure Metadata for
+ order-statistics and interval intersections-A, for
+ example, shows a tree whose each node contains two entries:
+ a floating-point key, and some size-type metadata
+ (in bold beneath it) that is the number of nodes in the
+ sub-tree. (E.g., the root has key 0.99, and has 5
+ nodes (including itself) in its sub-tree.) A container based
+ on this data structure can obviously answer efficiently
+ whether 0.3 is in the container object, but it can also
+ answer what is the order of 0.3 among all those in the
+ container object [clrs2001] (see Associative Container
+ Examples::Tree-Like-Based Containers (Trees and
+ Tries)).
+
+
As another example, Figure Metadata for order-statistics and
+ interval intersections-B shows a tree whose each node
+ contains two entries: a half-open geometric line interval,
+ and a number metadata (in bold beneath it) that is
+ the largest endpoint of all intervals in its sub-tree.
+ (E.g., the root describes the interval [20,
+ 36), and the largest endpoint in its sub-tree is 99.) A
+ container based on this data structure can obviously answer
+ efficiently whether [3, 41) is in the container
+ object, but it can also answer efficiently whether the
+ container object has intervals that intersect [3,
+ 41) (see Associative Container
+ Examples::Tree-Like-Based Containers (Trees and
+ Tries)). These types of queries are very useful in
+ geometric algorithms and lease-management algorithms.
+
+
It is important to note, however, that as the trees are
+ modified, their internal structure changes. To maintain
+ these invariants, one must supply some policy that is aware
+ of these changes (see Design::Associative
+ Containers::Tree-Based Containers::Node Invariants);
+ without this, it would be better to use a linked list (in
+ itself very efficient for these purposes).
The STL contains associative containers based on red-black
+ trees and collision-chaining hash tables. These are obviously
+ very useful, but they are not ideal for all types of
+ settings.
+
+
Figure Different underlying
+ data structures shows different underlying data structures
+ (the ones currently supported in pb_ds). A shows a
+ collision-chaining hash-table, B shows a probing hash-table, C
+ shows a red-black tree, D shows a splay tree, E shows a tree
+ based on an ordered vector(implicit in the order of the
+ elements), F shows a PATRICIA trie, and G shows a list-based
+ container with update policies.
Ideally, the underlying data structure of Cntnr
+ would not affect what can be done with r_cnt.
+ Unfortunately, this is not the case.
+
+
For example, if Cntnr is std::map, then
+ the function can use std::for_each(r_cnt.find(foo),
+ r_cnt.find(bar), foobar) in order to apply foobar
+ to all elements between foo and bar. If
+ Cntnr is a hash-based container, then this call's
+ results are undefined.
+
+
Also, if Cntnr is tree-based, the type and object
+ of the comparison functor can be accessed. If Cntnr is
+ hash based, these queries are nonsensical.
+
+
There are various other differences based on the container's
+ underlying data structure. For one, they can be constructed by,
+ and queried for, different policies. Furthermore:
+
+
+
Containers based on C, D, E and F store elements in a
+ meaningful order; the others store elements in a meaningless
+ (and probably time-varying) order. By implication, only
+ containers based on C, D, E and F can support erase
+ operations taking an iterator and returning an iterator to
+ the following element without performance loss (see Slightly Different Methods::Methods
+ Related to Erase).
+
+
Containers based on C, D, E, and F can be split and
+ joined efficiently, while the others cannot. Containers based
+ on C and D, furthermore, can guarantee that this is
+ exception-free; containers based on E cannot guarantee
+ this.
+
+
Containers based on all but E can guarantee that erasing
+ an element is exception free; containers based on E cannot
+ guarantee this. Containers based on all but B and E can
+ guarantee that modifying an object of their type does not
+ invalidate iterators or references to their elements, while
+ containers based on B and E cannot. Containers based on C, D,
+ and E can furthermore make a stronger guarantee, namely that
+ modifying an object of their type does not affect the order
+ of iterators.
Iterators are centric to the STL's design, because of the
+ container/algorithm/iterator decomposition that allows an
+ algorithm to operate on a range through iterators of some
+ sequence (e.g., one originating from a container).
+ Iterators, then, are useful because they allow going over a
+ sequence. The STL also uses iterators for accessing a
+ specific element - e.g., when an associative
+ container returns one through find. The STL, however,
+ consistently uses the same types of iterators for both
+ purposes: going over a range, and accessing a specific found
+ element. Before the introduction of hash-based containers to
+ the STL, this made sense (with the exception of priority
+ queues, which are discussed in Priority
+ Queues).
+
+
Using the STL's associative containers together with
+ non-order-preserving associative containers (and also because
+ of priority-queues container), there is a possible need for
+ different types of iterators for self-organizing containers -
+ the iterator concept seems overloaded to mean two different
+ things (in some cases). The following subsections explain this;
+ Tutorial::Associative
+ Containers::Point-Type and Range-Type Methods explains an
+ alternative design which does not complicate the use of
+ order-preserving containers, but is better for unordered
+ containers; Design::Associative
+ Containers::Data-Structure Genericity::Point-Type and
+ Range-Type Methods explains the design further.
Suppose cntnr is some associative container, and
+ say c is an object of type cntnr. Then what
+ will be the outcome of
+
+std::for_each(c.find(1), c.find(5), foo);
+
+
+
If cntnr is a tree-based container object, then an
+ in-order walk will apply foo to the relevant elements,
+ e.g., as in Figure Range
+ iteration in different data structures -A. If c is
+ a hash-based container, then the order of elements between any
+ two elements is undefined (and probably time-varying); there is
+ no guarantee that the elements traversed will coincide with the
+ logical elements between 1 and 5, e.g., as in
+ Figure Range iteration in different
+ data structures-B.
+
+
+
+
Range iteration in different
+ data structures.
+
+
In our opinion, this problem is not caused just because
+ red-black trees are order preserving while collision-chaining
+ hash tables are (generally) not - it is more fundamental. Most
+ of the STL's containers order sequences in a well-defined
+ manner that is determined by their interface: calling
+ insert on a tree-based container modifies its sequence
+ in a predictable way, as does calling push_back on a
+ list or a vector. Conversely, collision-chaining hash tables,
+ probing hash tables, priority queues, and list-based containers
+ (which are very useful for "multimaps") are self-organizing
+ data structures; the effect of each operation modifies their
+ sequences in a manner that is (practically) determined by their
+ implementation.
+
+
Consequently, applying an algorithm to a sequence obtained
+ from most containers may or may not make sense, but
+ applying it to a sub-sequence of a self-organizing container
+ does not.
Suppose c is some collision-chaining hash-based
+ container object, and one calls c.find(3). Then what
+ composes the returned iterator?
+
+
Figure Point-type
+ iterators in hash tables-A shows the simplest (and most
+ efficient) implementation of a collision-chaining hash table.
+ The little box marked point_iterator shows an object
+ that contains a pointer to the element's node. Note that this
+ "iterator" has no way to move to the next element (i.e.,
+ it cannot support operator++). Conversely, the
+ little box marked iterator stores both a pointer to
+ the element, as well as some other information (e.g.,
+ the bucket number of the element). the second iterator, then,
+ is "heavier" than the first one- it requires more time and
+ space. If we were to use a different container to
+ cross-reference into this hash-table using these iterators - it
+ would take much more space. As noted in Using Point-Type Iterators for
+ Range-Type Operations, nothing much can be done by
+ incrementing these iterators, so why is this extra information
+ needed?
+
+
Alternatively, one might create a collision-chaining
+ hash-table where the lists might be linked, forming a
+ monolithic total-element list, as in Figure Point-type iterators in hash
+ tables-B (this seems similar to the Dinkumware design
+ [dinkumware_stl]).
+ Here the iterators are as light as can be, but the hash-table's
+ operations are more complicated.
+
+
+
+
Point-type iterators in hash tables.
+
+
It should be noted that containers based on
+ collision-chaining hash-tables are not the only ones with this
+ type of behavior; many other self-organizing data structures
+ display it as well.
Following the call to erase, what is the validity
+ of it: can it be de-referenced? can it be
+ incremented?
+
+
The answer depends on the underlying data structure of the
+ container. Figure Effect of erase in different
+ underlying data structures shows three cases: A1 and A2
+ show a red-black tree; B1 and B2 show a probing hash-table; C1
+ and C2 show a collision-chaining hash table.
+
+
+
+
Effect of erase in different underlying
+ data structures.
+
+
+
Erasing 5 from A1 yields A2. Clearly, an iterator to 3
+ can be de-referenced and incremented. The sequence of
+ iterators changed, but in a way that is well-defined by the
+ interface.
+
+
Erasing 5 from B1 yields B2. Clearly, an iterator to 3 is
+ not valid at all - it cannot be de-referenced or incremented;
+ the order of iterators changed in a way that is (practically)
+ determined by the implementation and not by the
+ interface.
+
+
Erasing 5 from C1 yields C2. Here the situation is more
+ complicated. On the one hand, there is no problem in
+ de-referencing it. On the other hand, the order of
+ iterators changed in a way that is (practically) determined
+ by the implementation and not by the
+ interface.
+
+
+
So in classic STL, it is not always possible to express
+ whether it is valid or not. This is true also for
+ insert, e.g.. Again, the iterator concept seems
+ overloaded.
[meyers02both]
+ points out that a class's methods should comprise only
+ operations which depend on the class's internal structure;
+ other operations are best designed as external functions.
+ Possibly, therefore, the STL's associative containers lack some
+ useful methods, and provide some other methods which would be
+ better left out (e.g., [sgi_stl] ).
Order-preserving STL associative containers provide the
+ method
+
+iterator
+ erase
+ (iterator it)
+
which takes an iterator, erases the corresponding element,
+and returns an iterator to the following element. Also hash-based
+STL associative containers provide this method. This seemingly
+increases genericity between associative containers, since,
+ e.g., it is possible to use
+
in order to erase from a container object
+ c all element which match a predicate pred.
+ However, in a different sense this actually
+ decreases genericity: an integral implication of
+ this method is that tree-based associative containers'
+ memory use is linear in the total number of elements they
+ store, while hash-based containers' memory use is unbounded
+ in the total number of elements they store. Assume a
+ hash-based container is allowed to decrease its size when
+ an element is erased. Then the elements might be rehashed,
+ which means that there is no "next" element - it is simply
+ undefined. Consequently, it is possible to infer from the
+ fact that STL hash-based containers provide this method
+ that they cannot downsize when elements are erased
+ (Performance
+ Tests::Hash-Based Container Tests quantifies this.) As
+ a consequence, different code is needed to manipulate
+ different containers, assuming that memory should be
+ conserved. pb_ds's non-order preserving
+ associative containers omit this method.
+
+
+
All of pb_ds's associative containers include a
+ conditional-erase method
+
which erases all elements matching a predicate. This is
+probably the only way to ensure linear-time multiple-item erase
+which can actually downsize a container.
+
+
+
STL associative containers provide methods for
+ multiple-item erase of the form
+
+size_type
+ erase
+ (It b,
+ It e)
+
erasing a range of elements given by a pair of iterators. For
+tree-based or trie-based containers, this can implemented more
+efficiently as a (small) sequence of split and join operations. For
+other, unordered, containers, this method isn't much better than an
+external loop. Moreover, if c is a hash-based container,
+then, e.g., c.erase(c.find(2), c.find(5)) is almost
+certain to do something different than erasing all elements whose
+keys are between 2 and 5, and is likely to produce other undefined
+behavior.
+
It is well-known that tree-based and trie-based container
+ objects can be efficiently split or joined [clrs2001]. Externally splitting
+ or joining trees is super-linear, and, furthermore, can throw
+ exceptions. Split and join methods, consequently, seem good
+ choices for tree-based container methods, especially, since as
+ noted just before, they are efficient replacements for erasing
+ sub-sequences. Performance
+ Tests::Tree-Like-Based Container Tests quantifies this.
STL associative containers provide methods of the form
+
+template<
+ class It>
+size_type
+ insert
+ (It b,
+ It e);
+
for inserting a range of elements given by a pair of
+iterators. At best, this can be implemented as an external loop,
+or, even more efficiently, as a join operation (for the case of
+tree-based or trie-based containers). Moreover, these methods seem
+similar to constructors taking a range given by a pair of
+iterators; the constructors, however, are transactional, whereas
+the insert methods are not; this is possibly confusing.
+
+
Associative containers are parametrized by policies
+ allowing to test key equivalence; e.g. a hash-based
+ container can do this through its equivalence functor, and a
+ tree-based container can do this through its comparison
+ functor. In addition, some STL associative containers have
+ global function operators, e.g.,
+ operator== and operator<=,
+ that allow comparing entire associative containers.
+
+
In our opinion, these functions are better left out. To
+ begin with, they do not significantly improve over an external
+ loop. More importantly, however, they are possibly misleading -
+ operator==, for example, usually checks for
+ equivalence, or interchangeability, but the associative
+ container cannot check for values' equivalence, only keys'
+ equivalence; also, are two containers considered equivalent if
+ they store the same values in different order? this is an
+ arbitrary decision.
Maps (or sets) allow mapping (or storing) unique-key values.
+ The STL, however, also supplies associative containers which
+ map (or store) multiple values with equivalent keys:
+ std::multimap, std::multiset,
+ std::tr1::unordered_multimap, and
+ unordered_multiset. We first discuss how these might
+ be used, then why we think it is best to avoid them.
+
+
Suppose one builds a simple bank-account application that
+ records for each client (identified by an std::string)
+ and account-id (marked by an unsigned long) -
+ the balance in the account (described by a
+ float). Suppose further that ordering this
+ information is not useful, so a hash-based container is
+ preferable to a tree based container. Then one can use
which hashes every combination of client and
+account-id. This might work well, except for the fact that it
+is now impossible to efficiently list all of the accounts of a
+specific client (this would practically require iterating over all
+entries). Instead, one can use
+
which hashes every client, and decides equivalence
+based on client only. This will ensure that all accounts
+belonging to a specific user are stored consecutively.
+
+
Also, suppose one wants an integers' priority queue
+ (i.e., a container that supports push,
+ pop, and top operations, the last of which
+ returns the largest int) that also supports
+ operations such as find and lower_bound. A
+ reasonable solution is to build an adapter over
+ std::set<int>. In this adapter,
+ e.g., push will just call the tree-based
+ associative container's insert method; pop
+ will call its end method, and use it to return the
+ preceding element (which must be the largest). Then this might
+ work well, except that the container object cannot hold
+ multiple instances of the same integer (push(4),
+ e.g., will be a no-op if 4 is already in the
+ container object). If multiple keys are necessary, then one
+ might build the adapter over an
+ std::multiset<int>.
+
+
STL non-unique-mapping containers, then, are
+ useful when (1) a key can be decomposed in to a primary key and
+ a secondary key, (2) a key is needed multiple times, or (3) any
+ combination of (1) and (2).
+
+
Figure Non-unique mapping
+ containers in the STL's design shows how the STL's design
+ works internally; in this figure nodes shaded equally represent
+ equivalent-key values. Equivalent keys are stored consecutively
+ using the properties of the underlying data structure: binary
+ search trees (Figure Non-unique
+ mapping containers in the STL's design-A) store
+ equivalent-key values consecutively (in the sense of an
+ in-order walk) naturally; collision-chaining hash tables
+ (Figure Non-unique mapping
+ containers in the STL's design-B) store equivalent-key
+ values in the same bucket, the bucket can be arranged so that
+ equivalent-key values are consecutive.
+
+
+
+
Non-unique mapping containers in the STL's
+ design.
+
+
Put differently, STL non-unique mapping
+ associative-containers are associative containers that map
+ primary keys to linked lists that are embedded into the
+ container. Figure Effect of
+ embedded lists in STL multimaps shows again the two
+ containers from Figure Non-unique
+ mapping containers in the STL's design, this time with the
+ embedded linked lists of the grayed nodes marked
+ explicitly.
+
+
+
+
Effect of embedded lists in STL multimaps.
+
+
These embedded linked lists have several disadvantages.
+
+
+
The underlying data structure embeds the linked lists
+ according to its own consideration, which means that the
+ search path for a value might include several different
+ equivalent-key values. For example, the search path for the
+ the black node in either of Figures Non-unique mapping containers in the
+ STL's design A or B, includes more than a single gray
+ node.
+
+
The links of the linked lists are the underlying
+ data structures' nodes, which typically are quite structured.
+ E.g., in the case of tree-based containers (Figure
+ Effect of embedded lists in STL
+ multimaps-B), each "link" is actually a node with three
+ pointers (one to a parent and two to children), and a
+ relatively-complicated iteration algorithm. The linked lists,
+ therefore, can take up quite a lot of memory, and iterating
+ over all values equal to a given key (e.g., through
+ the return value of the STL's equal_range) can be
+ expensive.
+
+
The primary key is stored multiply; this uses more
+ memory.
+
+
Finally, the interface of this design excludes several
+ useful underlying data structures. E.g., of all the
+ unordered self-organizing data structures, practically only
+ collision-chaining hash tables can (efficiently) guarantee
+ that equivalent-key values are stored consecutively.
+
+
+
The above reasons hold even when the ratio of secondary keys
+ to primary keys (or average number of identical keys) is small,
+ but when it is large, there are more severe problems:
+
+
+
The underlying data structures order the links inside
+ each embedded linked-lists according to their internal
+ considerations, which effectively means that each of the
+ links is unordered. Irrespective of the underlying
+ data structure, searching for a specific value can degrade to
+ linear complexity.
+
+
Similarly to the above point, it is impossible to apply
+ to the secondary keys considerations that apply to primary
+ keys. For example, it is not possible to maintain secondary
+ keys by sorted order.
+
+
While the interface "understands" that all equivalent-key
+ values constitute a distinct list (e.g., through
+ equal_range), the underlying data structure
+ typically does not. This means, e.g., that operations
+ such as erasing from a tree-based container all values whose
+ keys are equivalent to a a given key can be super-linear in
+ the size of the tree; this is also true also for several
+ other operations that target a specific list.
+
+
+
In pb_ds, therefore, all associative containers map
+ (or store) unique-key values. One can (1) map primary keys to
+ secondary associative-containers (i.e., containers of
+ secondary keys) or non-associative containers (2) map identical
+ keys to a size-type representing the number of times they
+ occur, or (3) any combination of (1) and (2). Instead of
+ allowing multiple equivalent-key values, pb_ds
+ supplies associative containers based on underlying
+ data structures that are suitable as secondary
+ associative-containers (see Associative-Container
+ Performance Tests::Observations::Mapping-Semantics
+ Considerations).
In the first example above, then, one would use an
+ associative container mapping each user to an associative
+ container which maps each application id to a start time (see
+ basic_multimap.cc);
+ in the second example, one would use an associative container
+ mapping each int to some size-type indicating
+ the number of times it logically occurs (see basic_multiset.cc).
Priority queues are containers that allow efficiently
+ inserting values and accessing the maximal value (in the sense
+ of the container's comparison functor); i.e., their
+ interface supports push and pop. The STL's
+ priority queues indeed support these methods, but they support
+ little else. For algorithmic and software-engineering purposes,
+ other methods are needed:
+
+
+
Many graph algorithms [clrs2001] require increasing a
+ value in a priority queue (again, in the sense of the
+ container's comparison functor), or joining two
+ priority-queue objects.
+
+
It is sometimes necessary to erase an arbitrary value in
+ a priority queue. For example, consider the select
+ function for monitoring file descriptors:
+
then, as the select manual page [select_man] states:
+
+
The nfds argument specifies the range of file
+ descriptors to be tested. The select() function tests file
+ descriptors in the range of 0 to nfds-1.
+
+
It stands to reason, therefore, that we might wish to
+ maintain a minimal value for nfds, and priority
+ queues immediately come to mind. Note, though, that when a
+ socket is closed, the minimal file description might
+ change; in the absence of an efficient means to erase an
+ arbitrary value from a priority queue, we might as well
+ avoid its use altogether.
STL containers typically support iterators. It is
+ somewhat unusual for std::priority_queue to omit
+ them (see, e.g., [meyers01stl]). One might
+ ask why do priority queues need to support iterators, since
+ they are self-organizing containers with a different purpose
+ than abstracting sequences. There are several reasons:
+
+
+
Iterators (even in self-organizing containers) are
+ useful for many purposes, e.g., cross-referencing
+ containers, serialization, and debugging code that uses
+ these containers.
+
+
The STL's hash-based containers support iterators,
+ even though they too are self-organizing containers with
+ a different purpose than abstracting sequences.
+
+
In STL-like containers, it is natural to specify the
+ interface of operations for modifying a value or erasing
+ a value (discussed previously) in terms of a iterators.
+ This is discussed further in Design::Priority
+ Queues::Iterators. It should be noted that the STL's
+ containers also use iterators for accessing and
+ manipulating a specific value. E.g., in hash-based
+ containers, one checks the existence of a key by
+ comparing the iterator returned by find to the
+ iterator returned by end, and not by comparing a
+ pointer returned by find to NULL.
There are three main implementations of priority queues: the
+ first employs a binary heap, typically one which uses a
+ sequence; the second uses a tree (or forest of trees), which is
+ typically less structured than an associative container's tree;
+ the third simply uses an associative container. These are
+ shown, respectively, in Figures Underlying Priority-Queue
+ Data-Structures A1 and A2, B, and C.
+
+
+
+
Underlying Priority-Queue Data-Structures.
+
+
No single implementation can completely replace any of the
+ others. Some have better push and pop
+ amortized performance, some have better bounded (worst case)
+ response time than others, some optimize a single method at the
+ expense of others, etc.. In general the "best"
+ implementation is dictated by the problem (see Performance
+ Tests::Priority Queues::Observations).
+
+
As with associative containers (see Associative Containers::Traits for
+ Underlying Data-Structures), the more implementations
+ co-exist, the more necessary a traits mechanism is for handling
+ generic containers safely and efficiently. This is especially
+ important for priority queues, since the invalidation
+ guarantees of one of the most useful data structures - binary
+ heaps - is markedly different than those of most of the
+ others.
Binary heaps are one of the most useful underlying
+ data structures for priority queues. They are very efficient in
+ terms of memory (since they don't require per-value structure
+ metadata), and have the best amortized push and
+ pop performance for primitive types (e.g.,
+ ints).
+
+
The STL's priority_queue implements this data
+ structure as an adapter over a sequence, typically
+ std::vector or std::deque, which correspond
+ to Figures Underlying
+ Priority-Queue Data-Structures A1 and A2, respectively.
+
+
This is indeed an elegant example of the adapter concept and
+ the algorithm/container/iterator decomposition (see [nelson96stlpql]). There are
+ possibly reasons, however, why a binary-heap priority queue
+ would be better implemented as a container instead of a
+ sequence adapter:
+
+
+
std::priority_queue cannot erase values from its
+ adapted sequence (irrespective of the sequence type). This
+ means that the memory use of an std::priority_queue
+ object is always proportional to the maximal number of values
+ it ever contained, and not to the number of values that it
+ currently contains (see Priority Queue
+ Text pop Memory Use Test); this implementation
+ of binary heaps acts very differently than other underlying
+ data structures (e.g., pairing heaps).
+
+
Some combinations of adapted sequences and value types
+ are very inefficient or just don't make sense. If one uses
+ std::priority_queue<std::vector<std::string>
+ > >, for example, then not only will each
+ operation perform a logarithmic number of
+ std::string assignments, but, furthermore, any
+ operation (including pop) can render the container
+ useless due to exceptions. Conversely, if one uses
+ std::priority_queue<std::deque<int> >
+ >, then each operation uses incurs a logarithmic
+ number of indirect accesses (through pointers) unnecessarily.
+ It might be better to let the container make a conservative
+ deduction whether to use the structure in Figures Underlying Priority-Queue
+ Data-Structures A1 or A2.
+
+
There does not seem to be a systematic way to determine
+ what exactly can be done with the priority queue.
+
+
+
If p is a priority queue adapting an
+ std::vector, then it is possible to iterate over
+ all values by using &p.top() and
+ &p.top() + p.size(), but this will not work
+ if p is adapting an std::deque; in any
+ case, one cannot use p.begin() and
+ p.end(). If a different sequence is adapted, it
+ is even more difficult to determine what can be
+ done.
+
+
If p is a priority queue adapting an
+ std::deque, then the reference return by
+ p.top() will remain valid until it is popped,
+ but if p adapts an std::vector, the
+ next push will invalidate it. If a different
+ sequence is adapted, it is even more difficult to
+ determine what can be done.
+
+
+
+
Sequence-based binary heaps can still implement
+ linear-time erase and modify operations.
+ This means that if one needs, e.g., to erase a small
+ (say logarithmic) number of values, then one might still
+ choose this underlying data structure. Using
+ std::priority_queue, however, this will generally
+ change the order of growth of the entire sequence of
+ operations.
Decides whether a metadata object should be moved to
+ the front of the list.
+
+
+
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_large.html b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_large.html
new file mode 100644
index 00000000000..e3b1a2cd6bc
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_large.html
@@ -0,0 +1,215 @@
+
+
+
+
+
+"Multimap" Text Find Timing Test with Large Average
+ Secondary-Key to Primary-Key Ratio
+
+
+
+
+
"Multimap" Text Find Timing Test with Large Average
+ Secondary-Key to Primary-Key Ratio
This test inserts a number of pairs into a container. The
+ first item of each pair is a string from an arbitrary text
+ [wickland96thirty], and
+ the second is a uniform i.i.d.integer. The container is a
+ "multimap" - it considers the first member of each pair as a
+ primary key, and the second member of each pair as a secondary
+ key (see Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys). There
+ are 100 distinct primary keys, and the ratio of secondary keys
+ to primary keys ranges to about 20.
+
The test measures the average find-time as a function of the
+ number of values inserted. For pb_ds's containers, it
+ finds the secondary key from a container obtained from finding
+ a primary key. For the native multimaps, it searches a range
+ obtained using std::equal_range on a primary key.
Figures NTG, NTM, and
+ NTL show the results for "multimaps" which
+ use a tree-based container for primary keys, in g++, msvc++, and
+ local,
+ respectively; Figures NHG, NHM, and NHL show the results for
+ "multimaps" which use a hash-based container for primary keys,
+ in g++,
+ msvc++,
+ and local,
+ respectively.
+
+
+
+
+
NTG: Native and primary tree-based multimap types find timing test - g++
In the above figure, the names in the legends have the following meaning:
This test inserts a number of pairs into a container. The
+ first item of each pair is a string from an arbitrary text
+ [wickland96thirty], and
+ the second is a uniform i.i.d.integer. The container is a
+ "multimap" - it considers the first member of each pair as a
+ primary key, and the second member of each pair as a secondary
+ key (see Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys). There
+ are 400 distinct primary keys, and the ratio of secondary keys
+ to primary keys ranges from 1 to 5.
+
The test measures the average find-time as a function of the
+ number of values inserted. For pb_ds's containers, it
+ finds the secondary key from a container obtained from finding
+ a primary key. For the native multimaps, it searches a range
+ obtained using std::equal_range on a primary key.
Figures NTG, NTM, and
+ NTL show the results for "multimaps" which
+ use a tree-based container for primary keys, in g++, msvc++, and
+ local,
+ respectively; Figures NHG, NHM, and NHL show the results for
+ "multimaps" which use a hash-based container for primary keys,
+ in g++,
+ msvc++,
+ and local,
+ respectively.
+
+
+
+
+
NTG: NHG Native and primary tree-based multimap types find timing test - g++
In the above figure, the names in the legends have the following meaning:
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png
new file mode 100644
index 00000000000..60e850937a9
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png
new file mode 100644
index 00000000000..a8fa261177b
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png
new file mode 100644
index 00000000000..11aa9e07b6a
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png
new file mode 100644
index 00000000000..f54369b15b4
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png
new file mode 100644
index 00000000000..b3d10612f79
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png
new file mode 100644
index 00000000000..035fd9389b6
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html
new file mode 100644
index 00000000000..00d4146d7dc
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html
@@ -0,0 +1,210 @@
+
+
+
+
+
+Hash-List "Multimap" Text Memory Use Test with Large
+ Average Secondary-Key to Primary-Key Ratio
+
+
+
+
+
"Multimap" Text Memory Use Test with Large Average
+ Secondary-Key to Primary-Key Ratio
This test inserts a number of pairs into a container. The
+ first item of each pair is a string from an arbitrary text
+ [wickland96thirty], and
+ the second is a uniform i.i.d.integer. The container is a
+ "multimap" - it considers the first member of each pair as a
+ primary key, and the second member of each pair as a secondary
+ key (see Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys). There
+ are 100 distinct primary keys. The test measures the memory use
+ as a function of the number of values inserted.
Figures NTG, NTM, and
+ NTL show the results for "multimaps" which
+ use a tree-based container for primary keys, in g++, msvc++, and
+ local,
+ respectively; Figures NHG, NHM, and NHL show the results for
+ "multimaps" which use a hash-based container for primary keys,
+ in g++,
+ msvc++,
+ and local,
+ respectively.
+
+
+
+
+
NTG: NHG Native and primary tree-based multimap types mem usage test - g++
In the above figure, the names in the legends have the following meaning:
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png
new file mode 100644
index 00000000000..51a3f8d61c1
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png
new file mode 100644
index 00000000000..8af7100c6e7
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png
new file mode 100644
index 00000000000..3a938c0bb0f
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png
new file mode 100644
index 00000000000..a992d8f7cfb
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png
new file mode 100644
index 00000000000..63c0c8db797
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png
new file mode 100644
index 00000000000..26841bd1073
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html
new file mode 100644
index 00000000000..63ec4a9c9db
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html
@@ -0,0 +1,212 @@
+
+
+
+
+
+Hash-List "Multimap" Text Memory Use Test with Small
+ Average Secondary-Key to Primary-Key Ratio
+
+
+
+
+
"Multimap" Text Memory Use Test with Small Average
+ Secondary-Key to Primary-Key Ratio
This test inserts a number of pairs into a container. The
+ first item of each pair is a string from an arbitrary text
+ [wickland96thirty], and
+ the second is a uniform i.i.d.integer. The container is a
+ "multimap" - it considers the first member of each pair as a
+ primary key, and the second member of each pair as a secondary
+ key (see Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys). There
+ are 100 distinct primary keys, and the ratio of secondary keys
+ to primary keys ranges to about 20.
+
The test measures the memory use as a function of the number
+ of values inserted.
Figures NTG, NTM, and
+ NTL show the results for "multimaps" which
+ use a tree-based container for primary keys, in g++, msvc++, and
+ local,
+ respectively; Figures NHG, NHM, and NHL show the results for
+ "multimaps" which use a hash-based container for primary keys,
+ in g++,
+ msvc++,
+ and local,
+ respectively.
+
+
+
+
+
NTG: Native and primary tree-based multimap types mem usage test - g++
In the above figure, the names in the legends have the following meaning:
This test inserts a number of pairs into a container. The
+ first item of each pair is a string from an arbitrary text
+ [wickland96thirty], and
+ the second is a uniform i.i.d.integer. The container is a
+ "multimap" - it considers the first member of each pair as a
+ primary key, and the second member of each pair as a secondary
+ key (see Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys). There
+ are 100 distinct primary keys, and the ratio of secondary keys
+ to primary keys ranges to about 20.
+
The test measures the memory use as a function of the number
+ of values inserted.
Figures NTG, NTM, and
+ NTL show the results for "multimaps" which
+ use a tree-based container for primary keys, in g++, msvc++, and
+ local,
+ respectively; Figures NHG, NHM, and NHL show the results for
+ "multimaps" which use a hash-based container for primary keys,
+ in g++,
+ msvc++,
+ and local,
+ respectively.
+
+
+
+
+
NTG: Native and primary tree-based multimap types insert timing test - g++
In the above figure, the names in the legends have the following meaning:
This test inserts a number of pairs into a container. The
+ first item of each pair is a string from an arbitrary text
+ [wickland96thirty], and
+ the second is a uniform i.i.d.integer. The container is a
+ "multimap" - it considers the first member of each pair as a
+ primary key, and the second member of each pair as a secondary
+ key (see Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys). There
+ are 400 distinct primary keys, and the ratio of secondary keys
+ to primary keys ranges from 1 to 5.
+
The test measures the average insert-time as a function of
+ the number of values inserted. For pb_ds's containers,
+ it inserts a primary key into the primary associative
+ container, then a secondary key into the secondary associative
+ container. For the native multimaps, it obtains a range using
+ std::equal_range, and inserts a value only if it was
+ not contained already.
Figures NTG, NTM, and
+ NTL show the results for "multimaps" which
+ use a tree-based container for primary keys, in g++, msvc++, and
+ local,
+ respectively; Figures NHG, NHM, and NHL show the results for
+ "multimaps" which use a hash-based container for primary keys,
+ in g++,
+ msvc++,
+ and local,
+ respectively.
+
+
+
+
+
NTG: Native and primary tree-based multimap types insert timing test - g++
In the above figure, the names in the legends have the following meaning:
Signifies an invalidation guarantee that includes all those
+ of its base, and additionally, that any point-type iterator,
+ pointer, or reference to a container object's mapped value type
+ is valid as long as its corresponding entry has not be erased,
+ regardless of modifications to the container object.
As mentioned in Tutorial::Priority Queues,
+ pb_ds::priority_queue
+ shares most of the same interface with std::priority_queue.
+ E.g. if q is a priority queue of type
+ Q, then q.top() will return the "largest"
+ value in the container (according to typename
+ Q::cmp_fn). pb_ds::priority_queue
+ has a larger (and very slightly different) interface than
+ std::priority_queue, however, since typically
+ push and pop are deemed insufficient for
+ manipulating priority-queues.
+
+
Different settings require different priority-queue
+ implementations which are described in Implementations; Traits
+ discusses ways to differentiate between the different traits of
+ different implementations.
There are many different underlying-data structures for
+ implementing priority queues. Unfortunately, most such
+ structures are oriented towards making push and
+ top efficient, and consequently don't allow efficient
+ access of other elements: for instance, they cannot support an efficient
+ find method. In the use case where it
+ is important to both access and "do something with" an
+ arbitrary value, one would be out of luck. For example, many graph algorithms require
+ modifying a value (typically increasing it in the sense of the
+ priority queue's comparison functor).
+
+
In order to access and manipulate an arbitrary value in a
+ priority queue, one needs to reference the internals of the
+ priority queue from some form of an associative container -
+ this is unavoidable. Of course, in order to maintain the
+ encapsulation of the priority queue, this needs to be done in a
+ way that minimizes exposure to implementation internals.
+
+
In pb_ds the priority queue's insert
+ method returns an iterator, which if valid can be used for subsequent modify and
+ erase operations. This both preserves the priority
+ queue's encapsulation, and allows accessing arbitrary values (since the
+ returned iterators from the push operation can be
+ stored in some form of associative container).
+
+
Priority queues' iterators present a problem regarding their
+ invalidation guarantees. One assumes that calling
+ operator++ on an iterator will associate it
+ with the "next" value. Priority-queues are
+ self-organizing: each operation changes what the "next" value
+ means. Consequently, it does not make sense that push
+ will return an iterator that can be incremented - this can have
+ no possible use. Also, as in the case of hash-based containers,
+ it is awkward to define if a subsequent push operation
+ invalidates a prior returned iterator: it invalidates it in the
+ sense that its "next" value is not related to what it
+ previously considered to be its "next" value. However, it might not
+ invalidate it, in the sense that it can be
+ de-referenced and used for modify and erase
+ operations.
+
+
Similarly to the case of the other unordered associative
+ containers, pb_ds uses a distinction between
+ point-type and range type iterators. A priority queue's iterator can always be
+ converted to a point_iterator, and a
+ const_iterator can always be converted to a
+ const_point_iterator.
+
+
The following snippet demonstrates manipulating an arbitrary
+ value:
+
+// A priority queue of integers.
+priority_queue<int> p;
+
+// Insert some values into the priority queue.
+priority_queue<int>::point_iterator it = p.push(0);
+
+p.push(1);
+p.push(2);
+
+// Now modify a value.
+p.modify(it, 3);
+
+assert(p.top() == 3);
+
It should be noted that an alternative design could embed an
+ associative container in a priority queue. Could, but most probably should not. To begin with, it should be noted that one
+ could always encapsulate a priority queue and an associative
+ container mapping values to priority queue iterators with no
+ performance loss. One cannot, however, "un-encapsulate" a
+ priority queue embedding an associative container, which might
+ lead to performance loss. Assume, that one needs to
+ associate each value with some data unrelated to priority
+ queues. Then using pb_ds's design, one could use an
+ associative container mapping each value to a pair consisting
+ of this data and a priority queue's iterator. Using the
+ embedded method would need to use two associative
+ containers. Similar problems might arise in cases where a value
+ can reside simultaneously in many priority queues.
Roughly speaking, any value that is both pushed and popped
+ from a priority queue must incur a logarithmic expense (in the
+ amortized sense). Any priority queue implementation that would
+ avoid this, would violate known bounds on comparison-based
+ sorting (see, e.g., [clrs2001] and brodal96priority]).
+
+
Most implementations do
+ not differ in the asymptotic amortized complexity of
+ push and pop operations, but they differ in
+ the constants involved, in the complexity of other operations
+ (e.g., modify), and in the worst-case
+ complexity of single operations. In general, the more
+ "structured" an implementation (i.e., the more internal
+ invariants it possesses) - the higher its amortized complexity
+ of push and pop operations.
+
+
pb_ds implements different algorithms using a
+ single class: priority_queue.
+ Instantiating the Tag template parameter, "selects"
+ the implementation:
+
+
+
Instantiating Tag = binary_heap_tag creates
+ a binary heap of the form in Figures Underlying Priority-Queue
+ Data-Structures A1 or A2. The former is internally
+ selected by priority_queue
+ if Value_Type is instantiated by a primitive type
+ (e.g., an int); the latter is
+ internally selected for all other types (e.g.,
+ std::string). This implementations is relatively
+ unstructured, and so has good push and pop
+ performance; it is the "best-in-kind" for primitive
+ types, e.g., ints. Conversely, it has
+ high worst-case performance, and can support only linear-time
+ modify and erase operations; this is
+ explained further in Traits.
+
+
Instantiating Tag = pairing_heap_tag
+ creates a pairing heap of the form in Figure Underlying Priority-Queue
+ Data-Structures B. This implementations too is relatively
+ unstructured, and so has good push and pop
+ performance; it is the "best-in-kind" for non-primitive
+ types, e.g., std:strings. It also has very
+ good worst-case push and join performance
+ (O(1)), but has high worst-case pop
+ complexity.
+
+
Instantiating Tag = binomial_heap_tag
+ creates a binomial heap of the form in Figure Underlying Priority-Queue
+ Data-Structures B. This implementations is more
+ structured than a pairing heap, and so has worse
+ push and pop performance. Conversely, it
+ has sub-linear worst-case bounds for pop,
+ e.g., and so it might be preferred in cases where
+ responsiveness is important.
+
+
Instantiating Tag = rc_binomial_heap_tag
+ creates a binomial heap of the form in Figure Underlying Priority-Queue
+ Data-Structures B, accompanied by a redundant counter
+ which governs the trees. This implementations is therefore
+ more structured than a binomial heap, and so has worse
+ push and pop performance. Conversely, it
+ guarantees O(1)push complexity, and so it
+ might be preferred in cases where the responsiveness of a
+ binomial heap is insufficient.
+
+
Instantiating Tag = thin_heap_tag creates a
+ thin heap of the form in Figure Underlying Priority-Queue
+ Data-Structures B. This implementations too is more
+ structured than a pairing heap, and so has worse
+ push and pop performance. Conversely, it
+ has better worst-case and identical amortized complexities
+ than a Fibonacci heap, and so might be more appropriate for
+ some graph algorithms.
Of course, one can use any order-preserving associative
+ container as a priority queue, as in Figure Underlying Priority-Queue
+ Data-Structures C, possibly by creating an adapter class
+ over the associative container (much as
+ std::priority_queue can adapt std::vector).
+ This has the advantage that no cross-referencing is necessary
+ at all; the priority queue itself is an associative container.
+ Most associative containers are too structured to compete with
+ priority queues in terms of push and pop
+ performance.
It would be nice if all priority queues could
+ share exactly the same behavior regardless of implementation. Sadly, this is not possible. Just one for instance is in join operations: joining
+ two binary heaps might throw an exception (not corrupt
+ any of the heaps on which it operates), but joining two pairing
+ heaps is exception free.
+
+
Tags and traits are very useful for manipulating generic
+ types. pb_ds::priority_queue
+ publicly defines container_category as one of the tags
+ discussed in Implementations. Given any
+ container Cntnr, the tag of the underlying
+ data structure can be found via typename
+ Cntnr::container_category; this is one of the types shown in
+ Figure Data-structure tag class
+ hierarchy.
+
+
+
+
Data-structure tag class hierarchy.
+
+
Additionally, a traits mechanism can be used to query a
+ container type for its attributes. Given any container
+ Cntnr, then pb_ds::container_traits<Cntnr>
+ is a traits class identifying the properties of the
+ container.
+
+
To find if a container might throw if two of its objects are
+ joined, one can use container_traits<Cntnr>::split_join_can_throw,
+ for example.
+
+
Different priority-queue implementations have different invalidation guarantees. This is
+ especially important, since as explained in Iterators, there is no way to access an arbitrary
+ value of priority queues except for iterators. Similarly to
+ associative containers, one can use
+ container_traits<Cntnr>::invalidation_guarantee
+ to get the invalidation guarantee type of a priority queue.
This has major implications, and constitutes a good reason to avoid
+ using binary heaps. A binary heap can perform modify
+ or erase efficiently given a valid point-type
+ iterator. However, inn order to supply it with a valid point-type
+ iterator, one needs to iterate (linearly) over all
+ values, then supply the relevant iterator (recall that a
+ range-type iterator can always be converted to a point-type
+ iterator). This means that if the number of modify or
+ erase operations is non-negligible (say
+ super-logarithmic in the total sequence of operations) - binary
+ heaps will perform badly.
+
+
+
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/pq_different_underlying_dss.png b/libstdc++-v3/docs/html/ext/pb_ds/pq_different_underlying_dss.png
new file mode 100644
index 00000000000..9d84791fc0d
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/pq_different_underlying_dss.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/pq_examples.html b/libstdc++-v3/docs/html/ext/pb_ds/pq_examples.html
new file mode 100644
index 00000000000..ee8e9305486
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/pq_examples.html
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+ Examples
+
+
+
+
+
This section describes performance tests and their results.
+ In the following, g++, msvc++, and local (the build used for generating this
+ documentation) stand for three different builds:
Compiler - g++ (GCC) 4.0.2 20050808 (prerelease)
+ (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software
+ Foundation, Inc. This is free software; see the source
+ for copying conditions. There is NO warranty; not even
+ for MERCHANTABILITY or FITNESS FOR A PARTICULAR
+ PURPOSE.
Compiler - Microsoft (R) 32-bit C/C++ Optimizing
+ Compiler Version 13.10.3077 for 80x86 Copyright (C)
+ Microsoft Corporation 1984-2002. All rights
+ reserved.
Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
+Copyright (C) 2006 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions. There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
The following table shows the complexities of the different
+ underlying data structures in terms of orders of growth. It is
+ interesting to note that this table implies something about the
+ constants of the operations as well (see Amortized push
+ and pop operations).
[std note 1] This
+ is not a property of the algorithm, but rather due to the fact
+ that the STL's priority queue implementation does not support
+ iterators (and consequently the ability to access a specific
+ value inside it). If the priority queue is adapting an
+ std::vector, then it is still possible to reduce this
+ to Θ(n) by adapting over the STL's adapter and
+ using the fact that top returns a reference to the
+ first value; if, however, it is adapting an
+ std::deque, then this is impossible.
+
[std note 2] As
+ with [std note 1], this is not a
+ property of the algorithm, but rather the STL's implementation.
+ Again, if the priority queue is adapting an
+ std::vector then it is possible to reduce this to
+ Θ(n), but with a very high constant (one must call
+ std::make_heap which is an expensive linear
+ operation); if the priority queue is adapting an
+ std::dequeu, then this is impossible.
+
[thin_heap_note] A thin heap has
+ &Theta(log(n)) worst case modify time
+ always, but the amortized time depends on the nature of the
+ operation: I) if the operation increases the key (in the sense
+ of the priority queue's comparison functor), then the amortized
+ time is O(1), but if II) it decreases it, then the
+ amortized time is the same as the worst case time. Note that
+ for most algorithms, I) is important and II) is not.
In many cases, a priority queue is needed primarily for
+ sequences of push and pop operations. All of
+ the underlying data structures have the same amortized
+ logarithmic complexity, but they differ in terms of
+ constants.
+
The table above shows that the different data structures are
+ "constrained" in some respects. In general, if a data structure
+ has lower worst-case complexity than another, then it will
+ perform slower in the amortized sense. Thus, for example a
+ redundant-counter binomial heap (priority_queue with
+ Tag = rc_binomial_heap_tag)
+ has lower worst-case push performance than a binomial
+ heap (priority_queue
+ with Tag = binomial_heap_tag),
+ and so its amortized push performance is slower in
+ terms of constants.
+
As the table shows, the "least constrained" underlying
+ data structures are binary heaps and pairing heaps.
+ Consequently, it is not surprising that they perform best in
+ terms of amortized constants.
In some graph algorithms, a decrease-key operation is
+ required [clrs2001];
+ this operation is identical to modify if a value is
+ increased (in the sense of the priority queue's comparison
+ functor). The table above and Priority Queue
+ Text modify Timing Test - I show that a thin heap
+ (priority_queue with
+ Tag = thin_heap_tag)
+ outperforms a pairing heap (priority_queue with
+ Tag =Tag = pairing_heap_tag),
+ but the rest of the tests show otherwise.
+
This makes it difficult to decide which implementation to
+ use in this case. Dijkstra's shortest-path algorithm, for
+ example, requires Θ(n)push and
+ pop operations (in the number of vertices), but
+ O(n2)modify operations, which can
+ be in practice Θ(n) as well. It is difficult to
+ find an a-priori characterization of graphs in which the
+ actual number of modify operations will dwarf
+ the number of push and pop operations.
The library contains a single comprehensive regression test.
+ For a given container type in pb_ds, the test creates
+ an object of the container type and an object of the
+ corresponding STL type (i.e.,
+ std::priority_queue). It then performs a random
+ sequence of methods with random arguments (e.g., pushes,
+ pops, and so forth) on both objects. At each operation, the
+ test checks the return value of the method, and optionally both
+ compares pb_ds's object with the STL's object as well
+ as performing other consistency checks on pb_ds's
+ object (e.g., that the size returned by the
+ size method corresponds to the distance between its
+ begin and end iterators).
+
+
Additionally, the test integrally checks exception safety
+ and resource leaks. This is done as follows. A special
+ allocator type, written for the purpose of the test, both
+ randomly throws an exceptions when allocations are performed,
+ and tracks allocations and de-allocations. The exceptions thrown
+ at allocations simulate memory-allocation failures; the
+ tracking mechanism checks for memory-related bugs (e.g.,
+ resource leaks and multiple de-allocations). Both
+ pb_ds's containers and the containers' value-types are
+ configured to use this allocator.
pb_ds has been successfully tested with the
+ following compilers:
+
+
+
g++ 3.3.1, 3.4.4, 4.0, 4.1, and what will be 4.2
+
+
Intel icpc 8.1 and 9
+
+
Visual C++ .Net 2005
+
+
+
The library contains only header files, and does not require
+ any other libraries except the STL. All classes are defined in
+ namespace pb_ds. The library internally uses
+ macros beginning with PB_DS (e.g., for header
+ guards), but #undefs anything it
+ #defines (except for header guards). Compiling
+ the library in an environment where macros beginning in
+ PB_DS are defined, may yield unpredictable results in
+ compilation, execution, or both.
+
+
Further dependencies are necessary to create the visual output
+ for the performance tests. To create these graphs, two additional
+ packages will be needed: pychart and Beautiful
+ Soup. Both are freely available.
+
Constructor taking some policy objects. r_cmp_fn will be copied by the
+ Cmp_Fn object of the
+ container object.
+
+
+
+
+
+
+template<
+ class It>
+ priority_queue
+ (It first_it,
+ It last_it)
+
+
+
+
+
Constructor taking iterators to a range of value_types. The
+ value_types
+ between first_it and
+ last_it will be inserted
+ into the container object.
+
+
+
+
+
+
+template<
+ class It>
+ priority_queue
+ (It first_it,
+ It last_it,
+ constcmp_fn &r_cmp_fn)
+
+
+
+
+
Constructor taking iterators to a range of value_types and some
+ policy objects The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_cmp_fn will be copied by the
+ cmp_fn object of the
+ container object.
This test inserts a number of values with i.i.d. integer
+ keys into a container using push , then removes them
+ using pop . It measures the average time for
+ push and pop as a function of the number of
+ values.
Figures NPG, NPM, and
+ NPL shows the results for the native
+ priority queues and pb_ds 's priority queues in
+ g++,
+ msvc++, and
+ local,
+ respectively.
+
+
+
+
+
NPG: Native and pb ds priority queue pushpop timing test - g++
In the above figure, the names in the legends have the following meaning:
At first glance it seems that the STL's vector-based
+ priority queue is approximately on par with pb_ds's
+ corresponding priority queue. There are two differences
+ however:
+
+
The STL's priority queue does not downsize the underlying
+ vector (or deque) as the priority queue becomes smaller
+ (see Priority Queue
+ Text pop Memory Use Test). It is therefore
+ gaining some speed at the expense of space.
+
From Priority
+ Queue Random Integer push and pop Timing
+ Test, it seems that the STL's priority queue is slower in
+ terms of pus operations. Since the number of
+ pop operations is at most that of push
+ operations, the test here is the "best" for the STL's
+ priority queue.
This test inserts a number of values with i.i.d integer keys
+ into a container using push . It measures the average
+ time for push as a function of the number of
+ values.
Figures NPG, NPM, and
+ NPL show the results for the native priority
+ queues and pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively; Figures NBPG, NBPM, and NBPL shows the
+ results for the binary-heap based native priority queues and
+ pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively
+
+
+
+
+
NPG: Native and pb ds priority queue push timing test - g++
In the above figure, the names in the legends have the following meaning:
Binary heaps are the most suited for sequences of
+ push and pop operations of primitive types
+ (e.g.ints). They are less constrained
+ than any other type, and since it is very efficient to store
+ such types in arrays, they outperform even pairing heaps. (See
+ Priority
+ Queue Text push Timing Test for the case of
+ non-primitive types.)
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ two containers, then merges the containers. It uses
+ join for pb_ds's priority queues; for the
+ STL's priority queues, it successively pops values from one
+ container and pushes them into the other. The test measures the
+ average time as a function of the number of values.
In this test the node-based heaps perform join in
+ either logarithmic or constant time. The binary heap requires
+ linear time, since the well-known heapify algorithm [clrs2001] is linear.
+
It would be possible to apply the heapify algorithm to the
+ STL containers, if they would support iteration (which they
+ don't). Barring iterators, it is still somehow possible to
+ perform linear-time merge on a std::vector-based STL
+ priority queue, using top() and size() (since
+ they are enough to expose the underlying array), but this is
+ impossible for a std::deque-based STL priority queue.
+ Without heapify, the cost is super-linear.
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png
new file mode 100644
index 00000000000..a48bb358605
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png
new file mode 100644
index 00000000000..1701b4d8a61
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png
new file mode 100644
index 00000000000..0575b99c0c3
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html
new file mode 100644
index 00000000000..6935957207c
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html
@@ -0,0 +1,204 @@
+
+
+
+
+
+Priority Queue Text Modify (Down) Timing Test
+
+
+
+
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ into a container then modifies each one "down" (i.e., it
+ makes it smaller). It uses modify for pb_ds's
+ priority queues; for the STL's priority queues, it pops values
+ from a container until it reaches the value that should be
+ modified, then pushes values back in. It measures the average
+ time for modify as a function of the number of
+ values.
Figures NPG, NPM, and
+ NPL show the results for the native priority
+ queues and pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively; Figures NRTG, NRTM, and NRTL show the results
+ for the pairing heap and thin heaps in g++, msvc++, and
+ local,
+ respectively,
+
+
+
+
+
NPG: Native and pb ds priority queue modify timing test - g++
In the above figure, the names in the legends have the following meaning:
It is interesting to note, however, that as opposed to that
+ test, a thin heap (priority_queue with
+ Tag = thin_heap_tag) is
+ outperformed by a pairing heap (priority_queue with
+ Tag = pairing_heap_tag).
+ In this case, both heaps essentially perform an erase
+ operation followed by a push operation. As the other
+ tests show, a pairing heap is usually far more efficient than a
+ thin heap, so this is not surprising.
+
Most algorithms that involve priority queues increase values
+ (in the sense of the priority queue's comparison functor), and
+ so Priority Queue
+ Text modify Timing Test - I is more interesting
+ than this test.
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png
new file mode 100644
index 00000000000..74cbc652369
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png
new file mode 100644
index 00000000000..2fa9c798804
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png
new file mode 100644
index 00000000000..20b66373667
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png
new file mode 100644
index 00000000000..ca901831eff
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png
new file mode 100644
index 00000000000..977d167186c
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png
new file mode 100644
index 00000000000..bf68bf99292
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html
new file mode 100644
index 00000000000..3db4639baa6
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html
@@ -0,0 +1,222 @@
+
+
+
+
+
+Priority Queue Text Modify (Up) Timing Test
+
+
+
+
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ into a container then modifies each one "up" (i.e., it
+ makes it larger). It uses modify for pb_ds's
+ priority queues; for the STL's priority queues, it pops values
+ from a container until it reaches the value that should be
+ modified, then pushes values back in. It measures the average
+ time for modify as a function of the number of
+ values.
The test checks the effect of different underlying
+ data structures (see Design::Priority
+ Queues::Implementations) for graph algorithms settings.
+ Note that making an arbitrary value larger (in the sense of the
+ priority queue's comparison functor) corresponds to
+ decrease-key in standard graph algorithms [clrs2001].
Figures NPG, NPM, and
+ NPL show the results for the native priority
+ queues and pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively; Figures NRTG, NRTM, and NRTL show the results
+ for the pairing heap and thin heaps in g++, msvc++, and
+ local,
+ respectively,
+
+
+
+
+
NPG: Native and pb ds priority queue modify timing test - g++
In the above figure, the names in the legends have the following meaning:
In this test pb_ds's binary heaps effectively
+ perform modify in linear time. As explained in Priority Queue Design::Traits,
+ given a valid point-type iterator, a binary heap can perform
+ modify logarithmically. The problem is that binary
+ heaps invalidate their find iterators with each modifying
+ operation, and so the only way to obtain a valid point-type
+ iterator is to iterate using a range-type iterator until
+ finding the appropriate value, then use the range-type iterator
+ for the modify operation.
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ a container, then pops them until only one is left in the
+ container. It measures the memory use as a function of the
+ number of values pushed to the container.
Figures NPG, NPM, and
+ NPL show the results for the native priority
+ queues and pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively.
+
+
+
+
+
NPG: Native and pb ds priority queue pop memory-use test - g++
In the above figure, the names in the legends have the following meaning:
The priority queue implementations (excluding the STL's) use
+ memory proportionally to the number of values they hold:
+ node-based implementations (e.g., a pairing heap) do so
+ naturally; pb_ds's binary heap de-allocates memory when
+ a certain lower threshold is exceeded.
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ a container using push , then removes them using
+ pop . It measures the average time for push
+ as a function of the number of values.
Figures NPG, NPM, and
+ NPL show the results for the native priority
+ queues and pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively; Figures NBRG, NBRM, and NBRL show the results
+ for the native priority queues and pb_ds's pairing
+ queues in g++, msvc++, and
+ local,
+ respectively.
+
+
+
+
+
NPG: Native tree and pb ds priority queue push and pop timing test - g++
In the above figure, the names in the legends have the following meaning:
These results are very similar to Priority Queue Text
+ push Timing Test. As stated there, pairing heaps
+ (priority_queue with
+ Tag = pairing_heap_tag)
+ are most suited for push and pop sequences of
+ non-primitive types such as strings. Observing these two tests,
+ one can note that a pairing heap outperforms the others in
+ terms of push operations, but equals binary heaps
+ (priority_queue with
+ Tag = binary_heap_tag) if
+ the number of push and pop operations is
+ equal. As the number of pop operations is at most
+ equal to the number of push operations, pairing heaps
+ are better in this case. See Priority
+ Queue Random Integer push and pop Timing
+ Test for a case which is different.
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ a container using push . It measures the average time
+ for push as a function of the number of values
+ pushed.
Figures NPG, NPM, and
+ NPL show the results for the native priority
+ queues and pb_ds 's priority queues in g++, msvc++, and
+ local,
+ respectively; Figures NBRG, NBRM, and NBRL shows the
+ results for the binary-heap based native priority queues and
+ pb_ds's pairing-heap priority queues in g++, msvc++, and
+ local,
+ respectively
+
+
+
+
+
NPG: Native and pb ds priority queue push timing test - g++
In the above figure, the names in the legends have the following meaning:
The STL's priority queues do not seem to perform well in
+ this case: the std::vector implementation needs to
+ perform a logarithmic sequence of string operations for each
+ operation, and the deque implementation is possibly hampered by
+ its need to manipulate a relatively-complex type (deques
+ support a O(1)push_front, even though it is
+ not used by std::priority_queue.)
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png
new file mode 100644
index 00000000000..61962704f71
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png b/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png
new file mode 100644
index 00000000000..83105202a48
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png
new file mode 100644
index 00000000000..2206cef5a90
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/range_invalidation_guarantee.html b/libstdc++-v3/docs/html/ext/pb_ds/range_invalidation_guarantee.html
new file mode 100644
index 00000000000..e59a257a540
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/range_invalidation_guarantee.html
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+ range_invalidation_guarantee Interface
+
+
+
+
+
+
range_invalidation_guarantee Interface
+
+
Signifies an invalidation guarantee that includes all those
+ of its base, and additionally, that any range-type iterator
+ (including the returns of begin() and end()) is in the correct
+ relative positions to other range-type iterators as long as its
+ corresponding entry has not be erased, regardless of
+ modifications to the container object.
[alexandrescu01modern] Andrei
+ Alexandrescu, Modern C++ Design: Generic Programming and
+ Design Patterns Applied, Addison-Wesley Publishing
+ Company, 2001
+
+
[andrew04mtf]
+ K. Andrew and D. Gleich, "MTF, Bit, and COMB: A Guide to
+ Deterministic and Randomized Algorithms for the List Update
+ Problem"
+
+
[austern00noset] Matthew Austern, "Why
+ You shouldn't use set - and What You Should Use
+ Instead", C++ Report, April, 2000
[dubhashi98neg] D. Dubashi, and D. Ranjan,
+ "Balls and bins: A study in negative dependence.", Random
+ Structures and Algorithms 13, 2 (1998), 99-124
+
+
[fagin79extendible] R. Fagin, J.
+ Nievergelt, N. Pippenger, and H. R. Strong, "Extendible
+ hashing - a fast access method for dynamic files", ACM Trans.
+ Database Syst. 4, 3 (1979), 315-344
[gamma95designpatterns] E. Gamma,
+ R. Helm, R. Johnson, and J. Vlissides, "Design Patterns -
+ Elements of Reusable Object-Oriented Software",
+ Addison-Wesley Publishing Company, Addison-Wesley, 1995
+
+
[garg86order]
+ A. K. Garg and C. C. Gotlieb, "Order-preserving key
+ transformations", Trans. Database Syst. 11, 2 (1986),
+ 213-234
+
+
[hyslop02making] J. Hyslop, and H.
+ Sutter, "Making a real hash of things", C++ Report, May
+ 2002
+
+
[jossutis01stl] N. M. Jossutis, "The C++
+ Standard Library - A Tutorial and Reference", Addison-Wesley
+ Publishing Company, Addison-Wesley, 2001
[kleft00sets]
+ Klaus Kleft and Angelika Langer, "Are Set Iterators Mutable
+ or Immutable?", C/C++ Users Jornal, October 2000
+
+
[knuth98sorting] D. E. Knuth, "The Art of
+ Computer Programming - Sorting and Searching", Addison-Wesley
+ Publishing Company, Addison-Wesley, 1998
+
+
[liskov98data] B. Liskov, "Data abstraction
+ and hierarchy", SIGPLAN Notices 23, 5 (May 1998)
+
+
[litwin80lh] W.
+ Litwin, "Linear hashing: A new tool for file and table
+ addressing", Proceedings of International Conference on Very
+ Large Data Bases (June 1980), pp. 212-223
[meyers01stl]
+ S. Meyers, "Effective STL: 50 Specific Ways to Improve Your
+ Use of the Standard Template Library", Addison-Wesley
+ Publishing Company, Addison-Wesley, 2001
+
+
[meyers02both] S. Meyers, "Class Template,
+ Member Template - or Both?", C/C++ Users Journal, 2003
+
+
[motwani95random] R. Motwani, and P.
+ Raghavan, "Randomized Algorithms", Cambridge University
+ Press
[sleator84amortized] D. D. Sleator
+ and R. E. Tarjan, "Amortized Efficiency of List Update
+ Problems", ACM Symposium on Theory of Computing, 1984
+
+
[sleator85self] D. D. Sleator and R. E.
+ Tarjan, "Self-Adjusting Binary Search Trees", ACM Symposium
+ on Theory of Computing, 1985
+
+
[stepanov94standard] A. A. Stepanov
+ and M. Lee", "The Standard Template Library"
+
+
[stroustrup97cpp] Bjarne Stroustrup,
+ The C++ Programming Langugage -3rd ed., Addison-Wesley
+ Publishing Company,Reading, MA, USA, 1997
+
+
[vandevoorde2002cpptemplates]
+ D. Vandevoorde, and N. M. Josuttis, "C++ Templates: The
+ Complete Guide", Addison-Wesley Publishing Company,
+ Addison-Wesley, 2002
Transforms the const key reference
+ r_keyinto the i-th position within the table. This
+ method is called for
+ each collision within the probe sequence.
This method is called only if this object indicated
+ resize is needed. The actual size of the table is size, and the number of entries in
+ it is num_entries.
Decides whether a metadata object should be moved to
+ the front of the list. A list-update based containers
+ object will call this method to decide whether to move a
+ node to the front of the list. The method should return
+ true if the node should be moved to the
+ front of the list.
+
+
metadata_reference is a reference to a
+ metadata_type.
+
+
+
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/simple_list.png b/libstdc++-v3/docs/html/ext/pb_ds/simple_list.png
new file mode 100644
index 00000000000..9a05d3f5e4f
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/simple_list.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/splay_tree_tag.html b/libstdc++-v3/docs/html/ext/pb_ds/splay_tree_tag.html
new file mode 100644
index 00000000000..98c56ce695f
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/splay_tree_tag.html
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+ splay_tree_tag Interface
+
+
+
+
+
Constructor taking some policy objects. r_cmp_fn will be copied by the
+ Cmp_Fn object of the
+ container object.
+
+
+
+
+
+
+template<
+ class It>
+ tree
+ (It first_it,
+ It last_it)
+
+
+
+
+
Constructor taking iterators to a range of
+ value_types. The value_types between first_it and last_it will be inserted into the
+ container object.
+
+
+
+
+
+
+template<
+ class It>
+ tree
+ (It first_it,
+ It last_it,
+ constcmp_fn &r_cmp_fn)
+
+
+
+
+
Constructor taking iterators to a range of value_types
+ and some policy objects The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object. r_cmp_fn will be copied by the
+ cmp_fn object of the
+ container object.
Tag specifies which underlying data structure
+ to use.
+
+
Node_Update is a policy for updating node
+ invariants. This is described in Node
+ Invariants.
+
+
Allocator is an allocator
+ type.
+
+
+
The Tag parameter specifies which underlying
+ data structure to use. Instantiating it by rb_tree_tag, splay_tree_tag, or
+ ov_tree_tag,
+ specifies an underlying red-black tree, splay tree, or
+ ordered-vector tree, respectively; any other tag is illegal.
+ Note that containers based on the former two contain more types
+ and methods than the latter (e.g.,
+ reverse_iterator and rbegin), and different
+ exception and invalidation guarantees.
Consider the two trees in Figures Some node invariants A and B. The first
+ is a tree of floats; the second is a tree of pairs, each
+ signifying a geometric line interval. Each element in a tree is refered to as a node of the tree. Of course, each of
+ these trees can support the usual queries: the first can easily
+ search for 0.4; the second can easily search for
+ std::make_pair(10, 41).
+
+
Each of these trees can efficiently support other queries.
+ The first can efficiently determine that the 2rd key in the
+ tree is 0.3; the second can efficiently determine
+ whether any of its intervals overlaps
+ std::make_pair(29,42) (useful in geometric
+ applications or distributed file systems with leases, for
+ example). (See tree_order_statistics.cc
+ and tree_intervals.cc
+ for examples.) It should be noted that an std::set can
+ only solve these types of problems with linear complexity.
+
+
In order to do so, each tree stores some metadata in
+ each node, and maintains node invariants clrs2001]. The first stores in
+ each node the size of the sub-tree rooted at the node; the
+ second stores at each node the maximal endpoint of the
+ intervals at the sub-tree rooted at the node.
+
+
+
+
Some node invariants.
+
+
Supporting such trees is difficult for a number of
+ reasons:
+
+
+
There must be a way to specify what a node's metadata
+ should be (if any).
+
+
Various operations can invalidate node invariants.
+ E.g., Figure Invalidation of node
+ invariants shows how a right rotation, performed on A,
+ results in B, with nodes x and y having
+ corrupted invariants (the grayed nodes in C); Figure Invalidation of node
+ invariants shows how an insert, performed on D, results
+ in E, with nodes x and y having corrupted
+ invariants (the grayed nodes in F). It is not feasible to
+ know outside the tree the effect of an operation on the nodes
+ of the tree.
+
+
The search paths of standard associative containers are
+ defined by comparisons between keys, and not through
+ metadata.
+
+
It is not feasible to know in advance which methods trees
+ can support. Besides the usual find method, the
+ first tree can support a find_by_order method, while
+ the second can support an overlaps method.
+
+
+
+
+
Invalidation of node invariants.
+
+
These problems are solved by a combination of two means:
+ node iterators, and template-template node updater
+ parameters.
Each tree-based container defines two additional iterator
+ types, const_node_iterator
+ and node_iterator.
+ These iterators allow descending from a node to one of its
+ children. Node iterator allow search paths different than those
+ determined by the comparison functor. tree
+ supports the methods:
The first pairs return node iterators corresponding to the
+ root node of the tree; the latter pair returns node iterators
+ corresponding to a just-after-leaf node.
The tree-based containers are parametrized by a
+ Node_Update template-template parameter. A tree-based
+ container instantiates Node_Update to some
+ node_update class, and publicly
+ subclasses node_update. Figure
+ A tree and its update
+ policy shows this scheme, as well as some predefined
+ policies (which are explained below).
+
+
+
+
A tree and its update policy.
+
+
node_update (an instantiation of
+ Node_Update) must define metadata_type as
+ the type of metadata it requires. For order statistics,
+ e.g., metadata_type might be size_t.
+ The tree defines within each node a metadata_type
+ object.
+
+
node_update must also define the following method
+ for restoring node invariants:
In this method, nd_it is a node_iterator
+ corresponding to a node whose A) all descendants have valid
+ invariants, and B) its own invariants might be violated;
+ end_nd_it is a const_node_iterator
+ corresponding to a just-after-leaf node. This method should
+ correct the node invariants of the node pointed to by
+ nd_it. For example, say node x in Figure
+ Restoring node
+ invariants-A has an invalid invariant, but its' children,
+ y and z have valid invariants. After the
+ invocation, all three nodes should have valid invariants, as in
+ Figure Restoring node
+ invariants-B.
+
+
+
+
Invalidation of node invariants.
+
+
When a tree operation might invalidate some node invariant,
+ it invokes this method in its node_update base to
+ restore the invariant. For example, Figure Insert update sequence diagram shows
+ an insert operation (point A); the tree performs some
+ operations, and calls the update functor three times (points B,
+ C, and D). (It is well known that any insert,
+ erase, split or join, can restore
+ all node invariants by a small number of node invariant updates
+ [clrs2001].)
+
+
+
+
Insert update sequence diagram.
+
+
To complete the description of the scheme, three questions
+ need to be answered:
+
+
+
How can a tree which supports order statistics define a
+ method such as find_by_order?
+
+
How can the node updater base access methods of the
+ tree?
+
+
How can the following cyclic dependency be resolved?
+ node_update is a base class of the tree, yet it
+ uses node iterators defined in the tree (its child).
+
+
+
The first two questions are answered by the fact that
+ node_update (an instantiation of
+ Node_Update) is a public base class
+ of the tree. Consequently:
+
+
+
Any public methods of node_update are
+ automatically methods of the tree [alexandrescu01modern].
+ Thus an order-statistics node updater, tree_order_statistics_node_update
+ defines the find_by_order method; any tree
+ instantiated by this policy consequently supports this method
+ as well.
+
+
In C++, if a base class declares a method as
+ virtual, it is virtual in its
+ subclasses. If node_update needs to access one of
+ the tree's methods, say the member function end, it simply
+ declares that method as virtual
+ abstract.
+
+
+
The cyclic dependency is solved through template-template
+ parameters. Node_Update is parametrized by the tree's node iterators, its comparison
+ functor, and its allocator type. Thus,
+ instantiations of Node_Update have all information required.
+
+
pb_ds assumes that constructing a metadata object and modifying it
+ are exception free. Suppose that during some method, say
+ insert, a metadata-related operation
+ (e.g., changing the value of a metadata) throws an
+ exception. Ack! Rolling back the method is unusually complex.
+
+
In Interface::Concepts::Null
+ Policy Classes a distinction was made between redundant
+ policies and null policies. Node invariants show a
+ case where null policies are required.
+
+
Assume a regular tree is required, one which need not
+ support order statistics or interval overlap queries.
+ Seemingly, in this case a redundant policy - a policy which
+ doesn't affect nodes' contents would suffice. This, would lead
+ to the following drawbacks:
+
+
+
Each node would carry a useless metadata object, wasting
+ space.
+
+
The tree cannot know if its Node_Update policy
+ actually modifies a node's metadata (this is halting
+ reducible). In Figure Useless update path ,
+ assume the shaded node is inserted. The tree would have to
+ traverse the useless path shown to the root, applying
+ redundant updates all the way.
+
+
+
+
+
Useless update path.
+
+
A null policy class, null_tree_node_update
+ solves both these problems. The tree detects that node
+ invariants are irrelevant, and defines all accordingly.
Tree-based containers support split and join methods.
+ It is possible to split a tree so that it passes
+ all nodes with keys larger than a given key to a different
+ tree. These methods have the following advantages over the
+ alternative of externally inserting to the destination
+ tree and erasing from the source tree:
+
+
+
These methods are efficient - red-black trees are split
+ and joined in poly-logarithmic complexity; ordered-vector
+ trees are split and joined at linear complexity. The
+ alternatives have super-linear complexity.
+
+
Aside from orders of growth, these operations perform
+ few allocations and de-allocations. For red-black trees, allocations are not performed,
+ and the methods are exception-free.
Finds an entry by order. Returns a const_iterator to
+ the entry with the order order, or a const_iterator to
+ the container object's end if order is at least the size of the
+ container object.
Finds an entry by order. Returns an iterator to the entry
+ with the order order, or
+ an iterator to
+ the container object's end if order is at least the size of the
+ container object.
Returns the order of a key within a sequence. For
+ example, if r_key is the
+ smallest key, this method will return 0; if r_key is a key between the smallest
+ and next key, this method will return 1; if r_key is a key larger than the
+ largest key, this method will return the size of r_c.
This test creates a container, inserts random integers into
+ the the container, and then checks the order-statistics of the
+ container's values. (If the container is one of pb_ds
+ 's trees, it does this with the order_of_key method of
+ tree_order_statistics_node_update
+ ; otherwise, it uses the find method and
+ std::distance .) It measures the average time for such
+ queries as a function of the number of values inserted.
In this test, the native red-black tree can support
+ order-statistics queries only externally, by performing a
+ find (alternatively, lower_bound or
+ upper_bound ) and then using std::distance .
+ This is clearly linear, and it is not that surprising that the
+ cost is high.
+
pb_ds 's tree-based containers use in this test the
+ order_of_key method of tree_order_statistics_node_update.
+ This method has only linear complexity in the length of the
+ root-node path. Unfortunately, the average path of a splay tree
+ (tree
+ with Tag =splay_tree_tag ) can
+ be higher than logarithmic; the longest path of a red-black
+ tree (tree
+ with Tag =rb_tree_tag ) is
+ logarithmic in the number of elements. Consequently, the splay
+ tree has worse performance than the red-black tree.
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png
new file mode 100644
index 00000000000..bdb00d07a7f
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_local.png b/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_local.png
new file mode 100644
index 00000000000..2b921743f7c
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png
new file mode 100644
index 00000000000..76dcbee44fd
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_random_int_find_find_timing_test.html b/libstdc++-v3/docs/html/ext/pb_ds/tree_random_int_find_find_timing_test.html
new file mode 100644
index 00000000000..9317cfc948d
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/tree_random_int_find_find_timing_test.html
@@ -0,0 +1,160 @@
+
+
+
+
+
+Tree Text Find Timing Test
+
+
+
+
+
Tree-Based and Trie-Based Text find Find Timing
+ Test
This test inserts a number of values with keys from an
+ arbitrary text ([wickland96thirty]) into
+ a container, then performs a series of finds using
+ find. It measures the average time for find
+ as a function of the number of values inserted.
+
(The test was executed with text_find_timing_test
+ thirty_years_among_the_dead_preproc.txt 200 200 2100)
For this setting, a splay tree (tree
+ with Tag =splay_tree_tag)
+ does not do well. This is possibly due to two
+ reasons:
+
+
A splay tree is not guaranteed to be balanced
+ [motwani95random].
+ If a splay tree contains n nodes, its
+ average root-leaf path can be m >>
+ log(n).
+
Assume a specific root-leaf search path has
+ length m, and the search-target node has
+ distance m' from the root. A red-black
+ tree will require m + 1 comparisons to
+ find the required node; a splay tree will require
+ 2 m' comparisons. A splay tree,
+ consequently, can perform many more comparisons
+ than a red-black tree.
+
+
An ordered-vector tree (tree
+ with Tag =ov_tree_tag),
+ a red-black tree (tree
+ with Tag =rb_tree_tag),
+ and the native red-black tree all share
+ approximately the same performance.
+
An ordered-vector tree is slightly slower than
+ red-black trees, since it requires, in order to
+ find a key, more math operations than they do.
+ Conversely, an ordered-vector tree requires far
+ lower space than the others. ([austern00noset],
+ however, seems to have an implementation that is
+ also faster than a red-black tree).
+
A PATRICIA trie (trie
+ with Tag =pat_trie_tag)
+ has good look-up performance, due to its large
+ fan-out in this case. In this setting, a PATRICIA
+ trie has lookup performance comparable to a hash
+ table (see Hash-Based
+ Text find Find Timing Test), but it is
+ order preserving. This is not that surprising,
+ since a large fan-out PATRICIA trie works like a
+ hash table with collisions resolved by a sub-trie.
+ A large fan-out PATRICIA trie does not do well on
+ modifications (see Tree-Based and
+ Trie-Based Text Insert Timing Test). It is
+ possibly beneficial to semi-static settings,
+ therefore.
This test a container, inserts into a number of values,
+ splits the container at the median, and joins the two
+ containers. (If the containers are one of pb_ds 's
+ trees, it splits and joins with the split and
+ join method; otherwise, it uses the erase and
+ insert methods.) It measures the time for splitting
+ and joining the containers as a function of the number of
+ values inserted.
In this test, the native red-black trees must be split and
+ joined externally, through a sequence of erase and
+ insert operations. This is clearly super-linear, and
+ it is not that surprising that the cost is high.
+
pb_ds 's tree-based containers use in this test the
+ split and join methods, which have lower
+ complexity: the join method of a splay tree ( tree
+ with Tag =splay_tree_tag ) is
+ quadratic in the length of the longest root-leaf path, and
+ linear in the total number of elements; the join
+ method of a red-black tree ( tree
+ with Tag =rb_tree_tag ) or an
+ ordered-vector tree ( tree
+ with Tag =ov_tree_tag ) is linear
+ in the number of elements.
+
Asides from orders of growth, pb_ds 's trees access
+ their allocator very little in these operations, and some of
+ them do not access it at all. This leads to lower constants in
+ their complexity, and, for some containers, to exception-free
+ splits and joins (which can be determined via container_traits).
+
It is important to note that split and
+ join are not esoteric methods - they are the most
+ efficient means of erasing a contiguous range of values from a
+ tree based container.
+
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_gcc.png b/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_gcc.png
new file mode 100644
index 00000000000..88867eca6bd
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_gcc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_local.png b/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_local.png
new file mode 100644
index 00000000000..131d24a1a12
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_local.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_msvc.png b/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_msvc.png
new file mode 100644
index 00000000000..37ed1b2e7c0
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/tree_split_join_timing_test_msvc.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/tree_tag.html b/libstdc++-v3/docs/html/ext/pb_ds/tree_tag.html
new file mode 100644
index 00000000000..e4b20607805
--- /dev/null
+++ b/libstdc++-v3/docs/html/ext/pb_ds/tree_tag.html
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+ tree_tag Interface
+
+
+
+
+
This test inserts a number of values with keys from an
+ arbitrary text ([wickland96thirty]) into
+ a container, then performs a series of finds using
+ find. It measures the average time for find
+ as a function of the number of values inserted.
+
(The test was executed with text_find_timing_test
+ thirty_years_among_the_dead_preproc.txt 200 200 2100)
For this setting, a splay tree (tree
+ with Tag =splay_tree_tag) does
+ not do well. This is possibly due to two reasons:
+
+
A splay tree is not guaranteed to be balanced [motwani95random]. If a
+ splay tree contains n nodes, its average root-leaf
+ path can be m >> log(n).
+
Assume a specific root-leaf search path has length
+ m, and the search-target node has distance m'
+ from the root. A red-black tree will require m + 1
+ comparisons to find the required node; a splay tree will
+ require 2 m' comparisons. A splay tree, consequently,
+ can perform many more comparisons than a red-black tree.
+
+
An ordered-vector tree (tree
+ with Tag =ov_tree_tag), a red-black
+ tree (tree
+ with Tag =rb_tree_tag), and the
+ native red-black tree all share approximately the same
+ performance.
+
An ordered-vector tree is slightly slower than red-black
+ trees, since it requires, in order to find a key, more math
+ operations than they do. Conversely, an ordered-vector tree
+ requires far lower space than the others. ([austern00noset], however,
+ seems to have an implementation that is also faster than a
+ red-black tree).
+
A PATRICIA trie (trie
+ with Tag =pat_trie_tag) has good
+ look-up performance, due to its large fan-out in this case. In
+ this setting, a PATRICIA trie has look-up performance comparable
+ to a hash table (see Hash-Based Text
+ find Find Timing Test), but it is order
+ preserving. This is not that surprising, since a large-fan-out
+ PATRICIA trie works like a hash table with collisions resolved
+ by a sub-trie. A large-fan-out PATRICIA trie does not do well on
+ modifications (see Tree-Based and Trie-Based
+ Text Insert Timing Test). It is possibly beneficial to
+ semi-static settings, therefore.
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ a container using insert . It measures the average
+ time for insert as a function of the number of values
+ inserted.
+
(The test was executed with tree_text_insert_timing_test
+ thirty_years_among_the_dead_preproc.txt 200 200 2100)
Figures NNTG, NVTG,
+ and NPTG show the results for the native
+ tree and pb_ds's node-based trees, the native tree and
+ pb_ds's vector-based trees, and the native tree
+ andpb_ds's PATRICIA-trie, respectively, in g++; Figures
+ NNTM, NVTM, and
+ NPTM show the same in msvc++; Figures
+ NNTL, NVTL, and
+ NPTL show the same in local.
+
+
+
+
+
NNTG: Native tree and node-based trees text insert timing test using insert - g++
In the above figure, the names in the legends have the following meaning:
Observing Figure NVTG, an ordered-vector
+ tree ( tree
+ with Tag =ov_tree_tag) performs
+ abysmally. Inserting into this type of tree has linear
+ complexity [ austern00noset].
+
Observing Figure NPTG , A PATRICIA trie
+ ( trie
+ with Tag =pat_trie_tag ) has
+ abysmal performance, as well. This is not that surprising,
+ since a large-fan-out PATRICIA trie works like a hash table with
+ collisions resolved by a sub-trie. Each time a collision is
+ encountered, a new "hash-table" is built A large fan-out
+ PATRICIA trie, however, doe does well in look-ups (see Tree-Based and
+ Trie-Based Text find Find Timing Test ). It is
+ possibly beneficial to semi-static settings, therefore.
This test inserts a number of values with keys from an
+ arbitrary text ([ wickland96thirty ]) into
+ a container, then performs a series of finds using
+ find . It is different than Tree-Based and
+ Trie-Based Text find Find Timing Test in the
+ sequence of finds it performs: this test performs multiple
+ find s on the same key before moving on to the next
+ key. It measures the average time for find as a
+ function of the number of values inserted.
For this setting, an ordered-vector tree ( tree
+ with Tag =ov_tree_tag ), a
+ red-black tree ( tree
+ with Tag =rb_tree_tag ), and the
+ native red-black tree all share approximately the same
+ performance.
+
A splay tree ( tree
+ with Tag =splay_tree_tag ) does
+ much better, since each (successful) find "bubbles" the
+ corresponding node to the root of the tree.
Constructor taking some policy objects. r_e_access_traits will be copied by
+ the E_Access_Traits
+ object of the container object.
+
+
+
+
+
+
+template<
+ class It>
+ trie
+ (It first_it,
+ It last_it)
+
+
+
+
+
Constructor taking iterators to a range of
+ value_types. The value_types between first_it and last_it will be inserted into the
+ container object.
+
+
+
+
+
+
+template<
+ class It>
+ trie
+ (It first_it,
+ It last_it,
+ constE_Access_Traits &r_e_access_traits)
+
+
+
+
+
Constructor taking iterators to a range of value_types
+ and some policy objects. The value_types between
+ first_it and
+ last_it will be inserted
+ into the container object.
Tag specifies which underlying data structure
+ to use, and is described shortly.
+
+
Node_Update is a policy for updating node
+ invariants. This is described in Node
+ Invariants.
+
+
Allocator is an allocator
+ type.
+
+
+
The Tag parameter specifies which underlying
+ data structure to use. Instantiating it by pat_trie_tag, specifies an
+ underlying PATRICIA trie (explained shortly); any other tag is
+ currently illegal.
A (PATRICIA) trie is similar to a tree, but with the
+ following differences:
+
+
+
It explicitly views keys as a sequence of elements.
+ E.g., a trie can view a string as a sequence of
+ characters; a trie can view a number as a sequence of
+ bits.
+
+
It is not (necessarily) binary. Each node has fan-out n
+ + 1, where n is the number of distinct
+ elements.
+
+
It stores values only at leaf nodes.
+
+
Internal nodes have the properties that A) each has at
+ least two children, and B) each shares the same prefix with
+ any of its descendant.
A trie inherently views its keys as sequences of elements.
+ For example, a trie can view a string as a sequence of
+ characters. A trie needs to map each of n elements to a
+ number in {0, n - 1}. For example, a trie can map a
+ character c to
+ static_cast<size_t>(c).
+
+
Seemingly, then, a trie can assume that its keys support
+ (const) iterators, and that the value_type of this
+ iterator can be cast to a size_t. There are several
+ reasons, though, to decouple the mechanism by which the trie
+ accesses its keys' elements from the trie:
+
+
+
In some cases, the numerical value of an element is
+ inappropriate. Consider a trie storing DNA strings. It is
+ logical to use a trie with a fan-out of 5 = 1 + |{'A', 'C',
+ 'G', 'T'}|. This requires mapping 'T' to 3, though.
+
+
In some cases the keys' iterators are different than what
+ is needed. For example, a trie can be used to search for
+ common suffixes, by using strings'
+ reverse_iterator. As another example, a trie mapping
+ UNICODE strings would have a huge fan-out if each node would
+ branch on a UNICODE character; instead, one can define an
+ iterator iterating over 8-bit (or less) groups.
+
+
+
trie is,
+ consequently, parametrized by E_Access_Traits -
+ traits which instruct how to access sequences' elements.
+ string_trie_e_access_traits
+ is a traits class for strings. Each such traits define some
+ types, e.g.,
+
+typename E_Access_Traits::const_iterator
+
+
+
is a const iterator iterating over a key's elements. The
+ traits class must also define methods for obtaining an iterator
+ to the first and last element of a key.
+
+
Figure A PATRICIA trie shows a
+ (PATRICIA) trie resulting from inserting the words: "I wish
+ that I could ever see a poem lovely as a trie" (which,
+ unfortunately, does not rhyme).
+
+
The leaf nodes contain values; each internal node contains
+ two typename E_Access_Traits::const_iterator
+ objects, indicating the maximal common prefix of all keys in
+ the sub-tree. For example, the shaded internal node roots a
+ sub-tree with leafs "a" and "as". The maximal common prefix is
+ "a". The internal node contains, consequently, to const
+ iterators, one pointing to 'a', and the other to
+ 's'.
Trie-based containers support node invariants, as do
+ tree-based containers (see Tree-Based
+ Containers::Node Invariants). There are two minor
+ differences, though, which, unfortunately, thwart sharing them
+ sharing the same node-updating policies:
+
+
+
A trie's Node_Update template-template
+ parameter is parametrized by E_Access_Traits, while
+ a tree's Node_Update template-template parameter is
+ parametrized by Cmp_Fn.
+
+
Tree-based containers store values in all nodes, while
+ trie-based containers (at least in this implementation) store
+ values in leafs.
+
+
+
Figure A trie and its update
+ policy shows the scheme, as well as some predefined
+ policies (which are explained below).
+
+
+
+
A trie and its update policy.
+
+
pb_ds offers the following pre-defined trie node
+ updating policies:
Trie-based containers support split and join methods; the
+ rationale is equal to that of tree-based containers supporting
+ these methods (see Tree-Based
+ Containers::Additional Methods).
Finds an entry by order. Returns a const_iterator to
+ the entry with the order order, or a const_iterator to
+ the container object's end if order is at least the size of the
+ container object.
Finds an entry by order. Returns an iterator to the entry
+ with the order order, or
+ an iterator to
+ the container object's end if order is at least the size of the
+ container object.
Returns the order of a key within a sequence. For
+ example, if r_key is the
+ smallest key, this method will return 0; if r_key is a key between the smallest
+ and next key, this method will return 1; if r_key is a key larger than the
+ largest key, this method will return the size of r_c.
Returns the order of a prefix within a sequence. For
+ eexample, if [b,
+ e] is the smallest
+ prefix, this method will return 0; if r_key is a key
+ bbetween the smallest and
+ next key, this method will return 1; if r_key is a key
+ larger than the largest key, this method will return the
+ size of r_c.
For the most part, pb_ds's containers have the same
+ interface as the STL's, except for the names used for the
+ container classes themselves. For example, this shows basic
+ operations on a collision-chaining hash-based container:
The container is called cc_hash_table as
+ opposed to unordered_map, since "unordered map" does
+ not necessarily mean a hash-based map (as the STL implicitly
+ implies). For example, list-based associative containers, which
+ are very useful for the construction of "multimaps" (see
+ Associative-Container
+ Performance Tests::Observations::Mapping-Semantics
+ Considerations), are also unordered. It is also not called
+ hash_map since there are more ways than one to
+ implement hash tables.
+
+
This snippet shows a red-black tree based container:
The container is called tree
+ as opposed to map, since "map" doesn't say that
+ much.
+
+
Most of the STL's familiar methods are unchanged.
+ E.g., being, end, size,
+ empty, and clear, do just the same as is
+ customary. Associative-Container
+ Examples::Basic use, and especially basic_map.cc,
+ show examples of this.
+
+
This isn't to say that things are exactly as one would expect,
+given the container requirments and interfaces in the C++
+standard.
+
+
+
The names of containers' policies and policy accessors are
+ different than those of the STL. For example, if C is
+ some type of hash-based container, then
+
+C::hash_fn
+
gives the type of its hash functor, and if c is some
+hash-based container object, then
+
+c.get_hash_fn()
+
+
+
will return a reference to its hash-functor object.
+
+
Similarly, if C is some type of tree-based
+ container, then
+
+C::cmp_fn
+
gives the type of its comparison functor, and if c
+is some tree-based container object, then
+
+c.get_cmp_fn()
+
+
+
will return a reference to its comparison-functor
+ object.
+
+
It would be nice to give names consistent with those in the
+ existing C++ standard (inclusive of TR1). Unfortunately, these
+ standard containers don't consistently name types and
+ methods. For example, std::tr1::unordered_map uses
+ hasher for the hash functor, but std::map uses
+ key_compare for the comparison functor. Also, we could
+ not find an accessor for std::tr1::unordered_map's hash
+ functor, but std::map uses compare for accessing
+ the comparison functor.
+
+
Instead, pb_ds attempts to be internally consistent, and
+uses standard-derived terminology if possible.
+
Since associative containers share parts of their interface,
+ they are organized as a class hierarchy; it is shown in Figure
+ Class hierarchy.
+
+
+
+
Class hierarchy.
+
+
Each type or method is defined in the most-common ancestor
+ in which it makes sense:
+ basic_map.cc
+ shows an example of most of the associative-container
+ types.
+
+
+
For example, all associative containers support iteration.
+ Consequently, container_base has the
+ interface:
and so all associative containers inherent this method.
+ Conversely, both collision-chaining and (general) probing
+ hash-based associative containers have a hash functor, so
+ basic_hash_table
+ has the interface:
In general, each of pb_ds's containers is
+ parametrized by more policies than those of the STL's. For
+ example, the STL's hash-based container is parametrized as
+ follows:
and so can be configured by key type, mapped type, a functor
+ that translates keys to unsigned integral types, an equivalence
+ predicate, an allocator, and an indicator whether to store hash
+ values with each entry. pb_ds's collision-chaining
+ hash-based container is parametrized as
and so can be configured by the first four types of
+ std::tr1::unordered_map, then a policy for translating
+ the key-hash result into a position within the table, then a
+ policy by which the table resizes, an indicator whether to
+ store hash values with each entry, and an allocator (which is
+ typically the last template parameter in STL containers).
+
+
Nearly all policy parameters have default values, so this
+ need not be considered for casual use. It is important to note,
+ however, that hash-based containers' policies can dramatically
+ alter their performance in different settings, and that
+ tree-based containers' policies can make them useful for other
+ purposes than just look-up.
Associative-containers' underlying data structures obviously
+ affect their performance; Unfortunately, they can also affect
+ their interface. When manipulating generically associative
+ containers, it is often useful to be able to statically
+ determine what they can support and what the cannot. (This was
+ discussed in Motivation::Associative
+ Containers::Data-Structure Genericity.)
+
+
Happily, the STL provides a good solution to a similar
+ problem - that of the different behavior of iterators. If
+ It is an iterator, then
In most cases, however, the exact underlying data structure
+ is not really important, but only one of its attributes:
+ whether it guarantees storing elements by key order, for
+ example. For this one can use
pb_ds differentiates between two types of methods
+ and iterators: point-type, and range-type. For example,
+ find and insert are point-type methods, since
+ they each deal with a specific element; their returned
+ iterators are point-type iterators. begin and
+ end are range-type methods, since they are not used to
+ find a specific element, but rather to go over all elements in
+ a container object; their returned iterators are range-type
+ iterators.
+
+
Most containers store elements in an order that is
+ determined by their interface. Correspondingly, it is fine that
+ their point-type iterators are synonymous with their range-type
+ iterators. For example, in the following snippet
+
+std::for_each(c.find(1), c.find(5), foo);
+
two point-type iterators (returned by find) are used
+for a range-type purpose - going over all elements whose key is
+between 1 and 5.
+
+
Conversely, the above snippet makes no sense for
+ self-organizing containers - ones that order (and reorder)
+ their elements by implementation. It would be nice to have a
+ uniform iterator system that would allow the above snippet to
+ compile only if it made sense.
+
+
This could trivially be done by specializing
+ std::for_each for the case of iterators returned by
+ std::tr1::unordered_map, but this would only solve the
+ problem for one algorithm and one container. Fundamentally, the
+ problem is that one can loop using a self-organizing
+ container's point-type iterators.
+
+
pb_ds's containers define two families of
+ iterators: const_point_iterator and
+ point_iterator are the iterator types returned by
+ point-type methods; const_iterator and
+ iterator are the iterator types returned by range-type
+ methods.
Design::Associative
+ Containers::Data-Structure Genericity::Point-Type and
+ Range-Type Methods and Iterators discusses the relationship
+ between point-type and range-type iterators in general; for
+ containers whose interface defines sequence order, however, it
+ is very simple: point-type and range-type iterators are exactly
+ the same, which means that the above snippet will compile if it
+ is used for an order-preserving associative container.
+
+
For self-organizing containers, however, (hash-based
+ containers as a special example), the preceding snippet will
+ not compile, because their point-type iterators do not support
+ operator++.
+
+
In any case, both for order-preserving and self-organizing
+ containers, the following snippet will compile:
+
+typename Cntnr::point_iterator it = c.find(2);
+
+
+
because a range-type iterator can always be converted to a
+ point-type iterator.
Motivation::Associative
+ Containers::Differentiating between Iterator Types also
+ raised the point that a container's iterators might have
+ different invalidation rules concerning their de-referencing
+ abilities and movement abilities. This now corresponds exactly
+ to the question of whether point-type and range-type iterators
+ are valid. As explained in Determining
+ Containers' Attributes, container_traits allows
+ querying a container for its data structure attributes. The
+ iterator-invalidation guarantees are certainly a property of
+ the underlying data structure, and so
Anyone familiar with the STL knows that there are four kinds
+ of associative containers: maps, sets, multimaps, and
+ multisets. Basic Use discussed how
+ to use maps, i.e. containers that associate each key to
+ some data.
+
+
Sets are associative containers that simply store keys -
+ they do not map them to anything. In the STL, each map class
+ has a corresponding set class. E.g.,
+ std::map<int, char> maps each
+ int to a char, but
+ std::set<int, char> simply stores
+ ints. In pb_ds, however, there are no
+ distinct classes for maps and sets. Instead, an associative
+ container's Mapped template parameter is a policy: if
+ it is instantiated by null_mapped_type, then it
+ is a "set"; otherwise, it is a "map". E.g.,
Once the Mapped template parameter is instantiated
+ by null_mapped_type, then
+ the "set" acts very similarly to the STL's sets - it does not
+ map each key to a distinct null_mapped_type object. Also,
+ , the container's value_type is essentially
+ its key_type - just as with the STL's sets. For a simple example, see basic_set.cc
+ .
+
+
The STL's multimaps and multisets allow, respectively,
+ non-uniquely mapping keys and non-uniquely storing keys. As
+ discussed in Motivation::Associative
+ Containers::Alternative to Multiple Equivalent Keys, the
+ reasons why this might be necessary are 1) that a key might be
+ decomposed into a primary key and a secondary key, 2) that a
+ key might appear more than once, or 3) any arbitrary
+ combination of 1)s and 2)s. Correspondingly,
+ one should use 1) "maps" mapping primary keys to secondary
+ keys, 2) "maps" mapping keys to size types, or 3) any arbitrary
+ combination of 1)s and 2)s. Thus, for example, an
+ std::multiset<int> might be used to store
+ multiple instances of integers, but using pb_ds's
+ containers, one might use
These "multimaps" and "multisets" might be confusing to
+ anyone familiar with the STL's std::multimap and
+ std::multiset, because there is no clear
+ correspondence between the two. For example, in some cases
+ where one uses std::multiset in the STL, one might use
+ in pb_ds a "multimap" of "multisets" - i.e., a
+ container that maps primary keys each to an associative
+ container that maps each secondary key to the number of times
+ it occurs.
The Value_Type, Cmp_Fn, and
+ Allocator parameters are the container's value type,
+ comparison-functor type, and allocator type, respectively;
+ these are very similar to the STL's priority queue. The
+ Tag parameter is different: there are a number of
+ pre-defined tag types corresponding to binary heaps, binomial
+ heaps, etc., and Tag should be instantiated
+ by one of them. Interface::Data-Structure Tags and
+ Traits::Data Structure Tags::Priority-Queues lists the
+ possible types, Priority-Queue
+ Design explains this further, and basic_priority_queue.cc
+ shows an example.
+
+
Note that as opposed to the STL's priority queue, priority_queue is not a
+ sequence-adapter; it is a regular container.
These types of operations are necessary for making priority
+ queues useful for different applications, especially graph
+ applications. Priority-Queue
+ Examples::Cross-Referencing gives some examples.
is its invalidation guarantee. Invalidation guarantees are
+ especially important regarding priority queues, since in
+ pb_ds's design, iterators are practically the only way
+ to manipulate them.
+
+
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/update_policy_cd.png b/libstdc++-v3/docs/html/ext/pb_ds/update_policy_cd.png
new file mode 100644
index 00000000000..115a751c350
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/update_policy_cd.png differ
diff --git a/libstdc++-v3/docs/html/ext/pb_ds/update_seq_diagram.png b/libstdc++-v3/docs/html/ext/pb_ds/update_seq_diagram.png
new file mode 100644
index 00000000000..880a50edf8e
Binary files /dev/null and b/libstdc++-v3/docs/html/ext/pb_ds/update_seq_diagram.png differ
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 9d9e34b2faa..23a4120fda5 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -198,247 +198,331 @@ backward_headers = \
${backward_srcdir}/backward_warning.h
-assoc_srcdir = ${glibcxx_srcdir}/include/ext/pb_assoc
-assoc_builddir = ./ext/pb_assoc
+pb_srcdir = ${glibcxx_srcdir}/include/ext/pb_ds
+pb_builddir = ./ext/pb_ds
-assoc_subdirs = \
- ${assoc_builddir}/detail \
- ${assoc_builddir}/detail/tree_assoc_cntnr \
- ${assoc_builddir}/detail/basic_assoc_cntnr \
- ${assoc_builddir}/detail/splay_tree_ \
- ${assoc_builddir}/detail/typelist \
- ${assoc_builddir}/detail/basic_hash_assoc_cntnr \
- ${assoc_builddir}/detail/cc_ht_map_ \
- ${assoc_builddir}/detail/gp_ht_map_ \
- ${assoc_builddir}/detail/tree_policy \
- ${assoc_builddir}/detail/resize_policy \
- ${assoc_builddir}/detail/bin_search_tree_ \
- ${assoc_builddir}/detail/basic_tree_assoc_cntnr \
- ${assoc_builddir}/detail/cc_hash_assoc_cntnr \
- ${assoc_builddir}/detail/value_type_adapter \
- ${assoc_builddir}/detail/lu_policy \
- ${assoc_builddir}/detail/gp_hash_assoc_cntnr \
- ${assoc_builddir}/detail/unordered_iterator \
- ${assoc_builddir}/detail/ov_tree_map_ \
- ${assoc_builddir}/detail/lu_assoc_cntnr \
- ${assoc_builddir}/detail/hash_fn \
- ${assoc_builddir}/detail/eq_fn \
- ${assoc_builddir}/detail/rb_tree_map_ \
- ${assoc_builddir}/detail/lu_map_
+pb_subdirs = \
+ ${pb_builddir}/detail \
+ ${pb_builddir}/detail/pairing_heap_ \
+ ${pb_builddir}/detail/splay_tree_ \
+ ${pb_builddir}/detail/list_update_map_ \
+ ${pb_builddir}/detail/typelist \
+ ${pb_builddir}/detail/basic_tree_policy \
+ ${pb_builddir}/detail/trie_policy \
+ ${pb_builddir}/detail/gp_hash_table_map_ \
+ ${pb_builddir}/detail/tree_policy \
+ ${pb_builddir}/detail/binomial_heap_base_ \
+ ${pb_builddir}/detail/resize_policy \
+ ${pb_builddir}/detail/bin_search_tree_ \
+ ${pb_builddir}/detail/binomial_heap_ \
+ ${pb_builddir}/detail/thin_heap_ \
+ ${pb_builddir}/detail/pat_trie_ \
+ ${pb_builddir}/detail/cc_hash_table_map_ \
+ ${pb_builddir}/detail/rc_binomial_heap_ \
+ ${pb_builddir}/detail/left_child_next_sibling_heap_ \
+ ${pb_builddir}/detail/unordered_iterator \
+ ${pb_builddir}/detail/binary_heap_ \
+ ${pb_builddir}/detail/ov_tree_map_ \
+ ${pb_builddir}/detail/hash_fn \
+ ${pb_builddir}/detail/eq_fn \
+ ${pb_builddir}/detail/rb_tree_map_ \
+ ${pb_builddir}/detail/list_update_policy
# The ability for make and the underlying host to deal with this
# unweildy list as one entire entity is not a sure thing, and may
-# cause build errors. Thus, split one list into five smaller ones.
-assoc_headers1 = \
- ${assoc_srcdir}/detail/tree_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/type_utils.hpp \
- ${assoc_srcdir}/detail/order_statistics_imp.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/d_find_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/extract_key.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/d_extract_key.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/splay_tree_.hpp \
- ${assoc_srcdir}/detail/splay_tree_/node.hpp \
- ${assoc_srcdir}/detail/splay_tree_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/splay_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_transform.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_apply.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_filter.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_at_index.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_contains.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_append.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_typelist_append.hpp \
- ${assoc_srcdir}/detail/ds_trait_imp.hpp \
- ${assoc_srcdir}/detail/basic_hash_assoc_cntnr/resize_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_hash_assoc_cntnr/constructors_destructor_fn_imps.hpp
+# cause build errors. Thus, split one list into many smaller
+# mini-lists, with the maximum size per mini-list of no more than 42.
-assoc_headers2 = \
- ${assoc_srcdir}/detail/cc_ht_map_/resize_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/find_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/erase_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/resize_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/debug_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/cmp_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/insert_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/find_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/cond_key_dtor_entry_dealtor.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/entry_list_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/constructor_destructor_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/erase_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/cc_ht_map_.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/standard_policies.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/insert_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/size_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/debug_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/resize_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/resize_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/find_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/erase_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/resize_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/debug_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/insert_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/find_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/constructor_destructor_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/erase_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/insert_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/gp_ht_map_.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/iterator_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/debug_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/resize_no_store_hash_fn_imps.hpp
+pb_headers1 = \
+ ${pb_srcdir}/assoc_container.hpp \
+ ${pb_srcdir}/exception.hpp \
+ ${pb_srcdir}/hash_policy.hpp \
+ ${pb_srcdir}/list_update_policy.hpp \
+ ${pb_srcdir}/priority_queue.hpp \
+ ${pb_srcdir}/tag_and_trait.hpp \
+ ${pb_srcdir}/tree_policy.hpp \
+ ${pb_srcdir}/trie_policy.hpp \
+ ${pb_srcdir}/detail/basic_tree_policy/basic_tree_policy_base.hpp \
+ ${pb_srcdir}/detail/basic_tree_policy/null_node_metadata.hpp \
+ ${pb_srcdir}/detail/basic_tree_policy/traits.hpp \
+ ${pb_srcdir}/detail/basic_types.hpp \
+ ${pb_srcdir}/detail/binary_heap_/binary_heap_.hpp \
+ ${pb_srcdir}/detail/binary_heap_/const_iterator.hpp \
+ ${pb_srcdir}/detail/binary_heap_/const_point_iterator.hpp \
+ ${pb_srcdir}/detail/binary_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/entry_cmp.hpp \
+ ${pb_srcdir}/detail/binary_heap_/entry_pred.hpp \
+ ${pb_srcdir}/detail/binary_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/resize_policy.hpp \
+ ${pb_srcdir}/detail/binary_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/binomial_heap_base_.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_/binomial_heap_.hpp \
+ ${pb_srcdir}/detail/binomial_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/bin_search_tree_.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp
-assoc_headers3 = \
- ${assoc_srcdir}/detail/tree_policy/order_statistics_imp.hpp \
- ${assoc_srcdir}/detail/tree_policy/null_node_updator_imp.hpp \
- ${assoc_srcdir}/detail/types_traits.hpp \
- ${assoc_srcdir}/detail/mapping_level_imp.hpp \
- ${assoc_srcdir}/detail/map_debug_base.hpp \
- ${assoc_srcdir}/detail/resize_policy/ht_prime_size_policy_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_prime_size_policy_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/size_base.hpp \
- ${assoc_srcdir}/detail/resize_policy/cc_hash_max_collision_resize_trigger_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_exponential_size_policy_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_standard_resize_policy_imp.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/find_iterators.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/node_iterators.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/bin_search_tree_.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/rotate_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/r_erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/r_range_iteration_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/r_erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/range_iteration_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/node_iteration_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp
+pb_headers2 = \
+ ${pb_srcdir}/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/node_iterators.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/point_iterators.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/r_erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/rotate_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/traits.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/cc_ht_map_.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/cmp_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/cond_key_dtor_entry_dealtor.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/constructor_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/constructor_destructor_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/debug_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/debug_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/entry_list_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/erase_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/erase_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/find_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/insert_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/insert_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/resize_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/resize_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/resize_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/size_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/standard_policies.hpp
-assoc_headers4 = \
- ${assoc_srcdir}/detail/assoc_cntnr_base.hpp \
- ${assoc_srcdir}/detail/ms_category_imp.hpp \
- ${assoc_srcdir}/detail/hash_types_traits.hpp \
- ${assoc_srcdir}/detail/typelist.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/invalidation_guarantee_selector.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/iterator.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/constructor_destructor_and_related.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/value_type_traits.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/ref_pair.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/it_value_type_traits.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/erase_if_pred.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/value_type_adapter.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/iterator_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_policy/mtf_lu_policy_imp.hpp \
- ${assoc_srcdir}/detail/lu_policy/counter_lu_policy_imp.hpp \
- ${assoc_srcdir}/detail/lu_policy/counter_lu_metadata_imp.hpp \
- ${assoc_srcdir}/detail/gp_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/find_iterator.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/iterator.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/const_iterator.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/const_find_iterator.hpp \
- ${assoc_srcdir}/detail/standard_policies.hpp \
- ${assoc_srcdir}/detail/standard_sizes.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/ov_tree_map_.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/node_iterators.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/cond_dtor.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/constructors_destructor_fn_imps.hpp
+pb_headers3 = \
+ ${pb_srcdir}/detail/cc_hash_table_map_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/cond_dealtor.hpp \
+ ${pb_srcdir}/detail/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/container_base_dispatch.hpp \
+ ${pb_srcdir}/detail/eq_fn/eq_by_less.hpp \
+ ${pb_srcdir}/detail/eq_fn/hash_eq_fn.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/constructor_destructor_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/debug_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/debug_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/erase_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/erase_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/find_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/find_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/gp_ht_map_.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/insert_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/insert_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/iterator_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/resize_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/resize_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/resize_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/standard_policies.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/hash_fn/direct_mask_range_hashing_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/direct_mod_range_hashing_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/linear_probe_fn_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/mask_based_range_hashing.hpp \
+ ${pb_srcdir}/detail/hash_fn/mod_based_range_hashing.hpp \
+ ${pb_srcdir}/detail/hash_fn/probe_fn_base.hpp \
+ ${pb_srcdir}/detail/hash_fn/quadratic_probe_fn_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/ranged_hash_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/ranged_probe_fn.hpp
+
+pb_headers4 = \
+ ${pb_srcdir}/detail/hash_fn/sample_probe_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/sample_ranged_hash_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/sample_ranged_probe_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/sample_range_hashing.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/const_iterator.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/const_point_iterator.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/left_child_next_sibling_heap_.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/node.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/null_metadata.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/constructor_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/entry_metadata_base.hpp \
+ ${pb_srcdir}/detail/list_update_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/lu_map_.hpp \
+ ${pb_srcdir}/detail/list_update_map_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_policy/counter_lu_metadata.hpp \
+ ${pb_srcdir}/detail/list_update_policy/counter_lu_policy_imp.hpp \
+ ${pb_srcdir}/detail/list_update_policy/mtf_lu_policy_imp.hpp \
+ ${pb_srcdir}/detail/list_update_policy/sample_update_policy.hpp \
+ ${pb_srcdir}/detail/map_debug_base.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/cond_dtor.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/node_iterators.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/ov_tree_map_.hpp
+
+pb_headers5 = \
+ ${pb_srcdir}/detail/ov_tree_map_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/traits.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/pairing_heap_.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/child_iterator.hpp \
+ ${pb_srcdir}/detail/pat_trie_/cond_dtor_entry_dealtor.hpp \
+ ${pb_srcdir}/detail/pat_trie_/const_child_iterator.hpp \
+ ${pb_srcdir}/detail/pat_trie_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/head.hpp \
+ ${pb_srcdir}/detail/pat_trie_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/insert_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/internal_node.hpp \
+ ${pb_srcdir}/detail/pat_trie_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/leaf.hpp \
+ ${pb_srcdir}/detail/pat_trie_/node_base.hpp \
+ ${pb_srcdir}/detail/pat_trie_/node_iterators.hpp \
+ ${pb_srcdir}/detail/pat_trie_/node_metadata_base.hpp \
+ ${pb_srcdir}/detail/pat_trie_/pat_trie_.hpp \
+ ${pb_srcdir}/detail/pat_trie_/point_iterators.hpp \
+ ${pb_srcdir}/detail/pat_trie_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/r_erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/rotate_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/split_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/split_join_branch_bag.hpp \
+ ${pb_srcdir}/detail/pat_trie_/synth_e_access_traits.hpp \
+ ${pb_srcdir}/detail/pat_trie_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/traits.hpp \
+ ${pb_srcdir}/detail/pat_trie_/update_fn_imps.hpp \
+ ${pb_srcdir}/detail/priority_queue_base_dispatch.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/debug_fn_imps.hpp
+
+pb_headers6 = \
+ ${pb_srcdir}/detail/rb_tree_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/node.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/rb_tree_.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/traits.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/rc_binomial_heap_.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/rc.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/resize_policy/cc_hash_max_collision_check_resize_trigger_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_exponential_size_policy_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_load_check_resize_trigger_size_base.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_prime_size_policy_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_standard_resize_policy_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/sample_resize_policy.hpp \
+ ${pb_srcdir}/detail/resize_policy/sample_resize_trigger.hpp \
+ ${pb_srcdir}/detail/resize_policy/sample_size_policy.hpp \
+ ${pb_srcdir}/detail/splay_tree_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/node.hpp \
+ ${pb_srcdir}/detail/splay_tree_/splay_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/splay_tree_.hpp \
+ ${pb_srcdir}/detail/splay_tree_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/traits.hpp \
+ ${pb_srcdir}/detail/standard_policies.hpp \
+ ${pb_srcdir}/detail/thin_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/erase_fn_imps.hpp
+
+pb_headers7 = \
+ ${pb_srcdir}/detail/thin_heap_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/thin_heap_.hpp \
+ ${pb_srcdir}/detail/thin_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/tree_policy/node_metadata_selector.hpp \
+ ${pb_srcdir}/detail/tree_policy/null_node_update_imp.hpp \
+ ${pb_srcdir}/detail/tree_policy/order_statistics_imp.hpp \
+ ${pb_srcdir}/detail/tree_policy/sample_tree_node_update.hpp \
+ ${pb_srcdir}/detail/tree_trace_base.hpp \
+ ${pb_srcdir}/detail/trie_policy/node_metadata_selector.hpp \
+ ${pb_srcdir}/detail/trie_policy/null_node_update_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/order_statistics_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/prefix_search_node_update_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/sample_trie_e_access_traits.hpp \
+ ${pb_srcdir}/detail/trie_policy/sample_trie_node_update.hpp \
+ ${pb_srcdir}/detail/trie_policy/string_trie_e_access_traits_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/trie_policy_base.hpp \
+ ${pb_srcdir}/detail/typelist_assoc_container.hpp \
+ ${pb_srcdir}/detail/typelist.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_append.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_apply.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_assoc_container_find.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_at_index.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_contains.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_filter.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_flatten.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_transform.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_typelist_append.hpp \
+ ${pb_srcdir}/detail/types_traits.hpp \
+ ${pb_srcdir}/detail/type_utils.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/const_iterator.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/const_point_iterator.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/iterator.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/point_iterator.hpp
-assoc_headers5 = \
- ${assoc_srcdir}/detail/lu_assoc_cntnr/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/hash_fn/linear_probe_fn_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/mod_based_range_hashing.hpp \
- ${assoc_srcdir}/detail/hash_fn/direct_mod_range_hashing_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/probe_fn_base.hpp \
- ${assoc_srcdir}/detail/hash_fn/ranged_probe_fn.hpp \
- ${assoc_srcdir}/detail/hash_fn/quadratic_probe_fn_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/direct_mask_range_hashing_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/ranged_hash_fn.hpp \
- ${assoc_srcdir}/detail/hash_fn/mask_based_range_hashing.hpp \
- ${assoc_srcdir}/detail/eq_fn/eq_by_less.hpp \
- ${assoc_srcdir}/detail/eq_fn/hash_eq_fn.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/node.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/rb_tree_.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/lu_map_.hpp \
- ${assoc_srcdir}/detail/lu_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/ms_trait_imp.hpp \
- ${assoc_srcdir}/detail/cond_dealtor.hpp \
- ${assoc_srcdir}/hash_policy.hpp \
- ${assoc_srcdir}/trivial_iterator_def.hpp \
- ${assoc_srcdir}/ds_trait.hpp \
- ${assoc_srcdir}/exception.hpp \
- ${assoc_srcdir}/tree_policy.hpp \
- ${assoc_srcdir}/lu_policy.hpp \
- ${assoc_srcdir}/ms_trait.hpp \
- ${assoc_srcdir}/assoc_cntnr.hpp \
- ${assoc_srcdir}/data_type.hpp
ext_srcdir = ${glibcxx_srcdir}/include/ext
@@ -696,7 +780,7 @@ endif
# CLEANFILES and all-local are kept up-to-date.
allstamped = \
stamp-std stamp-bits stamp-c_base stamp-c_compatibility \
- stamp-backward stamp-ext stamp-assoc stamp-tr1 stamp-debug stamp-host
+ stamp-backward stamp-ext stamp-pb stamp-tr1 stamp-debug stamp-host
# List of all files that are created by explicit building, editing, or
# catenation.
@@ -777,42 +861,54 @@ stamp-ext: ${ext_headers}
# Have to deal with nested include directories, gah! Strip off source
# directory before making the link.
-# XXX check ${assoc_headers}
-stamp-assoc:
- @if [ ! -d "${assoc_builddir}" ]; then \
- mkdir -p ${assoc_subdirs} ;\
+# XXX check ${pb_headers}
+stamp-pb:
+ @if [ ! -d "${pb_builddir}" ]; then \
+ mkdir -p ${pb_subdirs} ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers1}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers1}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(LN_S) $$h $${build_name} || true ;\
+ done ;\
+ fi
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers2}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(LN_S) $$h $${build_name} || true ;\
+ done ;\
+ fi
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers3}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers2}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers4}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers3}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers5}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers4}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers6}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers5}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers7}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- $(STAMP) stamp-assoc
+ $(STAMP) stamp-pb
stamp-tr1: ${tr1_headers}
@if [ ! -d "${tr1_builddir}" ]; then \
@@ -981,28 +1077,36 @@ install-headers:
$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${ext_builddir}
for file in ${ext_headers}; do \
$(INSTALL_DATA) $${file} $(DESTDIR)${gxx_include_dir}/${ext_builddir}; done
- $(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${assoc_builddir}
- for dir in ${assoc_subdirs}; do \
+ $(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${pb_builddir}
+ for dir in ${pb_subdirs}; do \
$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/$${dir} ; done
- for file in ${assoc_headers1}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers1}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
+ for file in ${pb_headers2}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
+ for file in ${pb_headers3}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers2}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers4}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers3}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers5}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers4}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers6}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers5}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers7}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${tr1_builddir}
for file in ${tr1_headers}; do \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index b1305309637..d389b1d1700 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -419,247 +419,329 @@ backward_headers = \
${backward_srcdir}/strstream \
${backward_srcdir}/backward_warning.h
-assoc_srcdir = ${glibcxx_srcdir}/include/ext/pb_assoc
-assoc_builddir = ./ext/pb_assoc
-assoc_subdirs = \
- ${assoc_builddir}/detail \
- ${assoc_builddir}/detail/tree_assoc_cntnr \
- ${assoc_builddir}/detail/basic_assoc_cntnr \
- ${assoc_builddir}/detail/splay_tree_ \
- ${assoc_builddir}/detail/typelist \
- ${assoc_builddir}/detail/basic_hash_assoc_cntnr \
- ${assoc_builddir}/detail/cc_ht_map_ \
- ${assoc_builddir}/detail/gp_ht_map_ \
- ${assoc_builddir}/detail/tree_policy \
- ${assoc_builddir}/detail/resize_policy \
- ${assoc_builddir}/detail/bin_search_tree_ \
- ${assoc_builddir}/detail/basic_tree_assoc_cntnr \
- ${assoc_builddir}/detail/cc_hash_assoc_cntnr \
- ${assoc_builddir}/detail/value_type_adapter \
- ${assoc_builddir}/detail/lu_policy \
- ${assoc_builddir}/detail/gp_hash_assoc_cntnr \
- ${assoc_builddir}/detail/unordered_iterator \
- ${assoc_builddir}/detail/ov_tree_map_ \
- ${assoc_builddir}/detail/lu_assoc_cntnr \
- ${assoc_builddir}/detail/hash_fn \
- ${assoc_builddir}/detail/eq_fn \
- ${assoc_builddir}/detail/rb_tree_map_ \
- ${assoc_builddir}/detail/lu_map_
+pb_srcdir = ${glibcxx_srcdir}/include/ext/pb_ds
+pb_builddir = ./ext/pb_ds
+pb_subdirs = \
+ ${pb_builddir}/detail \
+ ${pb_builddir}/detail/pairing_heap_ \
+ ${pb_builddir}/detail/splay_tree_ \
+ ${pb_builddir}/detail/list_update_map_ \
+ ${pb_builddir}/detail/typelist \
+ ${pb_builddir}/detail/basic_tree_policy \
+ ${pb_builddir}/detail/trie_policy \
+ ${pb_builddir}/detail/gp_hash_table_map_ \
+ ${pb_builddir}/detail/tree_policy \
+ ${pb_builddir}/detail/binomial_heap_base_ \
+ ${pb_builddir}/detail/resize_policy \
+ ${pb_builddir}/detail/bin_search_tree_ \
+ ${pb_builddir}/detail/binomial_heap_ \
+ ${pb_builddir}/detail/thin_heap_ \
+ ${pb_builddir}/detail/pat_trie_ \
+ ${pb_builddir}/detail/cc_hash_table_map_ \
+ ${pb_builddir}/detail/rc_binomial_heap_ \
+ ${pb_builddir}/detail/left_child_next_sibling_heap_ \
+ ${pb_builddir}/detail/unordered_iterator \
+ ${pb_builddir}/detail/binary_heap_ \
+ ${pb_builddir}/detail/ov_tree_map_ \
+ ${pb_builddir}/detail/hash_fn \
+ ${pb_builddir}/detail/eq_fn \
+ ${pb_builddir}/detail/rb_tree_map_ \
+ ${pb_builddir}/detail/list_update_policy
# The ability for make and the underlying host to deal with this
# unweildy list as one entire entity is not a sure thing, and may
-# cause build errors. Thus, split one list into five smaller ones.
-assoc_headers1 = \
- ${assoc_srcdir}/detail/tree_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/type_utils.hpp \
- ${assoc_srcdir}/detail/order_statistics_imp.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/d_find_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/extract_key.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/d_extract_key.hpp \
- ${assoc_srcdir}/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/splay_tree_.hpp \
- ${assoc_srcdir}/detail/splay_tree_/node.hpp \
- ${assoc_srcdir}/detail/splay_tree_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/splay_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/splay_tree_/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_transform.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_apply.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_filter.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_at_index.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_contains.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_append.hpp \
- ${assoc_srcdir}/detail/typelist/typelist_typelist_append.hpp \
- ${assoc_srcdir}/detail/ds_trait_imp.hpp \
- ${assoc_srcdir}/detail/basic_hash_assoc_cntnr/resize_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_hash_assoc_cntnr/constructors_destructor_fn_imps.hpp
-
-assoc_headers2 = \
- ${assoc_srcdir}/detail/cc_ht_map_/resize_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/find_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/erase_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/resize_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/debug_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/cmp_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/insert_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/find_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/cond_key_dtor_entry_dealtor.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/entry_list_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/constructor_destructor_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/erase_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/cc_ht_map_.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/standard_policies.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/insert_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/size_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/debug_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_ht_map_/resize_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/resize_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/find_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/erase_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/resize_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/debug_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/insert_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/find_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/constructor_destructor_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/erase_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/insert_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/gp_ht_map_.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/iterator_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/debug_no_store_hash_fn_imps.hpp \
- ${assoc_srcdir}/detail/gp_ht_map_/resize_no_store_hash_fn_imps.hpp
-
-assoc_headers3 = \
- ${assoc_srcdir}/detail/tree_policy/order_statistics_imp.hpp \
- ${assoc_srcdir}/detail/tree_policy/null_node_updator_imp.hpp \
- ${assoc_srcdir}/detail/types_traits.hpp \
- ${assoc_srcdir}/detail/mapping_level_imp.hpp \
- ${assoc_srcdir}/detail/map_debug_base.hpp \
- ${assoc_srcdir}/detail/resize_policy/ht_prime_size_policy_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_prime_size_policy_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/size_base.hpp \
- ${assoc_srcdir}/detail/resize_policy/cc_hash_max_collision_resize_trigger_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_exponential_size_policy_imp.hpp \
- ${assoc_srcdir}/detail/resize_policy/hash_standard_resize_policy_imp.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/find_iterators.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/node_iterators.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/bin_search_tree_.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/rotate_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/r_erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/r_range_iteration_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/r_erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/range_iteration_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/basic_tree_assoc_cntnr/node_iteration_fn_imps.hpp \
- ${assoc_srcdir}/detail/cc_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp
-
-assoc_headers4 = \
- ${assoc_srcdir}/detail/assoc_cntnr_base.hpp \
- ${assoc_srcdir}/detail/ms_category_imp.hpp \
- ${assoc_srcdir}/detail/hash_types_traits.hpp \
- ${assoc_srcdir}/detail/typelist.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/invalidation_guarantee_selector.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/iterator.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/constructor_destructor_and_related.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/value_type_traits.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/ref_pair.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/it_value_type_traits.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/erase_if_pred.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/value_type_adapter.hpp \
- ${assoc_srcdir}/detail/value_type_adapter/iterator_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_policy/mtf_lu_policy_imp.hpp \
- ${assoc_srcdir}/detail/lu_policy/counter_lu_policy_imp.hpp \
- ${assoc_srcdir}/detail/lu_policy/counter_lu_metadata_imp.hpp \
- ${assoc_srcdir}/detail/gp_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/find_iterator.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/iterator.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/const_iterator.hpp \
- ${assoc_srcdir}/detail/unordered_iterator/const_find_iterator.hpp \
- ${assoc_srcdir}/detail/standard_policies.hpp \
- ${assoc_srcdir}/detail/standard_sizes.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/ov_tree_map_.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/node_iterators.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/cond_dtor.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/ov_tree_map_/constructors_destructor_fn_imps.hpp
-
-assoc_headers5 = \
- ${assoc_srcdir}/detail/lu_assoc_cntnr/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_assoc_cntnr/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/hash_fn/linear_probe_fn_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/mod_based_range_hashing.hpp \
- ${assoc_srcdir}/detail/hash_fn/direct_mod_range_hashing_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/probe_fn_base.hpp \
- ${assoc_srcdir}/detail/hash_fn/ranged_probe_fn.hpp \
- ${assoc_srcdir}/detail/hash_fn/quadratic_probe_fn_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/direct_mask_range_hashing_imp.hpp \
- ${assoc_srcdir}/detail/hash_fn/ranged_hash_fn.hpp \
- ${assoc_srcdir}/detail/hash_fn/mask_based_range_hashing.hpp \
- ${assoc_srcdir}/detail/eq_fn/eq_by_less.hpp \
- ${assoc_srcdir}/detail/eq_fn/hash_eq_fn.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/node.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/split_join_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/rb_tree_.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/rb_tree_map_/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/lu_map_.hpp \
- ${assoc_srcdir}/detail/lu_map_/erase_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/policy_access_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/insert_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/find_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/constructor_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/info_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/iterators_fn_imps.hpp \
- ${assoc_srcdir}/detail/lu_map_/debug_fn_imps.hpp \
- ${assoc_srcdir}/detail/constructors_destructor_fn_imps.hpp \
- ${assoc_srcdir}/detail/ms_trait_imp.hpp \
- ${assoc_srcdir}/detail/cond_dealtor.hpp \
- ${assoc_srcdir}/hash_policy.hpp \
- ${assoc_srcdir}/trivial_iterator_def.hpp \
- ${assoc_srcdir}/ds_trait.hpp \
- ${assoc_srcdir}/exception.hpp \
- ${assoc_srcdir}/tree_policy.hpp \
- ${assoc_srcdir}/lu_policy.hpp \
- ${assoc_srcdir}/ms_trait.hpp \
- ${assoc_srcdir}/assoc_cntnr.hpp \
- ${assoc_srcdir}/data_type.hpp
+# cause build errors. Thus, split one list into many smaller
+# mini-lists, with the maximum size per mini-list of no more than 42.
+pb_headers1 = \
+ ${pb_srcdir}/assoc_container.hpp \
+ ${pb_srcdir}/exception.hpp \
+ ${pb_srcdir}/hash_policy.hpp \
+ ${pb_srcdir}/list_update_policy.hpp \
+ ${pb_srcdir}/priority_queue.hpp \
+ ${pb_srcdir}/tag_and_trait.hpp \
+ ${pb_srcdir}/tree_policy.hpp \
+ ${pb_srcdir}/trie_policy.hpp \
+ ${pb_srcdir}/detail/basic_tree_policy/basic_tree_policy_base.hpp \
+ ${pb_srcdir}/detail/basic_tree_policy/null_node_metadata.hpp \
+ ${pb_srcdir}/detail/basic_tree_policy/traits.hpp \
+ ${pb_srcdir}/detail/basic_types.hpp \
+ ${pb_srcdir}/detail/binary_heap_/binary_heap_.hpp \
+ ${pb_srcdir}/detail/binary_heap_/const_iterator.hpp \
+ ${pb_srcdir}/detail/binary_heap_/const_point_iterator.hpp \
+ ${pb_srcdir}/detail/binary_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/entry_cmp.hpp \
+ ${pb_srcdir}/detail/binary_heap_/entry_pred.hpp \
+ ${pb_srcdir}/detail/binary_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/resize_policy.hpp \
+ ${pb_srcdir}/detail/binary_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/binary_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/binomial_heap_base_.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_base_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_/binomial_heap_.hpp \
+ ${pb_srcdir}/detail/binomial_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/binomial_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/bin_search_tree_.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp
+
+pb_headers2 = \
+ ${pb_srcdir}/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/node_iterators.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/point_iterators.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/r_erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/rotate_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/bin_search_tree_/traits.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/cc_ht_map_.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/cmp_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/cond_key_dtor_entry_dealtor.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/constructor_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/constructor_destructor_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/debug_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/debug_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/entry_list_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/erase_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/erase_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/find_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/insert_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/insert_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/resize_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/resize_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/resize_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/size_fn_imps.hpp \
+ ${pb_srcdir}/detail/cc_hash_table_map_/standard_policies.hpp
+
+pb_headers3 = \
+ ${pb_srcdir}/detail/cc_hash_table_map_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/cond_dealtor.hpp \
+ ${pb_srcdir}/detail/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/container_base_dispatch.hpp \
+ ${pb_srcdir}/detail/eq_fn/eq_by_less.hpp \
+ ${pb_srcdir}/detail/eq_fn/hash_eq_fn.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/constructor_destructor_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/constructor_destructor_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/debug_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/debug_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/erase_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/erase_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/find_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/find_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/gp_ht_map_.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/insert_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/insert_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/iterator_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/resize_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/resize_no_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/resize_store_hash_fn_imps.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/standard_policies.hpp \
+ ${pb_srcdir}/detail/gp_hash_table_map_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/hash_fn/direct_mask_range_hashing_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/direct_mod_range_hashing_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/linear_probe_fn_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/mask_based_range_hashing.hpp \
+ ${pb_srcdir}/detail/hash_fn/mod_based_range_hashing.hpp \
+ ${pb_srcdir}/detail/hash_fn/probe_fn_base.hpp \
+ ${pb_srcdir}/detail/hash_fn/quadratic_probe_fn_imp.hpp \
+ ${pb_srcdir}/detail/hash_fn/ranged_hash_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/ranged_probe_fn.hpp
+
+pb_headers4 = \
+ ${pb_srcdir}/detail/hash_fn/sample_probe_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/sample_ranged_hash_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/sample_ranged_probe_fn.hpp \
+ ${pb_srcdir}/detail/hash_fn/sample_range_hashing.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/const_iterator.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/const_point_iterator.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/left_child_next_sibling_heap_.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/node.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/null_metadata.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/left_child_next_sibling_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/constructor_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/entry_metadata_base.hpp \
+ ${pb_srcdir}/detail/list_update_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_map_/lu_map_.hpp \
+ ${pb_srcdir}/detail/list_update_map_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/list_update_policy/counter_lu_metadata.hpp \
+ ${pb_srcdir}/detail/list_update_policy/counter_lu_policy_imp.hpp \
+ ${pb_srcdir}/detail/list_update_policy/mtf_lu_policy_imp.hpp \
+ ${pb_srcdir}/detail/list_update_policy/sample_update_policy.hpp \
+ ${pb_srcdir}/detail/map_debug_base.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/cond_dtor.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/node_iterators.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/ov_tree_map_.hpp
+
+pb_headers5 = \
+ ${pb_srcdir}/detail/ov_tree_map_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/ov_tree_map_/traits.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/pairing_heap_.hpp \
+ ${pb_srcdir}/detail/pairing_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/child_iterator.hpp \
+ ${pb_srcdir}/detail/pat_trie_/cond_dtor_entry_dealtor.hpp \
+ ${pb_srcdir}/detail/pat_trie_/const_child_iterator.hpp \
+ ${pb_srcdir}/detail/pat_trie_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/head.hpp \
+ ${pb_srcdir}/detail/pat_trie_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/insert_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/internal_node.hpp \
+ ${pb_srcdir}/detail/pat_trie_/iterators_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/leaf.hpp \
+ ${pb_srcdir}/detail/pat_trie_/node_base.hpp \
+ ${pb_srcdir}/detail/pat_trie_/node_iterators.hpp \
+ ${pb_srcdir}/detail/pat_trie_/node_metadata_base.hpp \
+ ${pb_srcdir}/detail/pat_trie_/pat_trie_.hpp \
+ ${pb_srcdir}/detail/pat_trie_/point_iterators.hpp \
+ ${pb_srcdir}/detail/pat_trie_/policy_access_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/r_erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/rotate_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/split_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/split_join_branch_bag.hpp \
+ ${pb_srcdir}/detail/pat_trie_/synth_e_access_traits.hpp \
+ ${pb_srcdir}/detail/pat_trie_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/pat_trie_/traits.hpp \
+ ${pb_srcdir}/detail/pat_trie_/update_fn_imps.hpp \
+ ${pb_srcdir}/detail/priority_queue_base_dispatch.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/debug_fn_imps.hpp
+
+pb_headers6 = \
+ ${pb_srcdir}/detail/rb_tree_map_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/node.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/rb_tree_.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/rb_tree_map_/traits.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/rc_binomial_heap_.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/rc.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/rc_binomial_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/resize_policy/cc_hash_max_collision_check_resize_trigger_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_exponential_size_policy_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_load_check_resize_trigger_size_base.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_prime_size_policy_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/hash_standard_resize_policy_imp.hpp \
+ ${pb_srcdir}/detail/resize_policy/sample_resize_policy.hpp \
+ ${pb_srcdir}/detail/resize_policy/sample_resize_trigger.hpp \
+ ${pb_srcdir}/detail/resize_policy/sample_size_policy.hpp \
+ ${pb_srcdir}/detail/splay_tree_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/erase_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/info_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/node.hpp \
+ ${pb_srcdir}/detail/splay_tree_/splay_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/splay_tree_.hpp \
+ ${pb_srcdir}/detail/splay_tree_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/splay_tree_/traits.hpp \
+ ${pb_srcdir}/detail/standard_policies.hpp \
+ ${pb_srcdir}/detail/thin_heap_/constructors_destructor_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/debug_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/erase_fn_imps.hpp
+
+pb_headers7 = \
+ ${pb_srcdir}/detail/thin_heap_/find_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/insert_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/split_join_fn_imps.hpp \
+ ${pb_srcdir}/detail/thin_heap_/thin_heap_.hpp \
+ ${pb_srcdir}/detail/thin_heap_/trace_fn_imps.hpp \
+ ${pb_srcdir}/detail/tree_policy/node_metadata_selector.hpp \
+ ${pb_srcdir}/detail/tree_policy/null_node_update_imp.hpp \
+ ${pb_srcdir}/detail/tree_policy/order_statistics_imp.hpp \
+ ${pb_srcdir}/detail/tree_policy/sample_tree_node_update.hpp \
+ ${pb_srcdir}/detail/tree_trace_base.hpp \
+ ${pb_srcdir}/detail/trie_policy/node_metadata_selector.hpp \
+ ${pb_srcdir}/detail/trie_policy/null_node_update_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/order_statistics_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/prefix_search_node_update_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/sample_trie_e_access_traits.hpp \
+ ${pb_srcdir}/detail/trie_policy/sample_trie_node_update.hpp \
+ ${pb_srcdir}/detail/trie_policy/string_trie_e_access_traits_imp.hpp \
+ ${pb_srcdir}/detail/trie_policy/trie_policy_base.hpp \
+ ${pb_srcdir}/detail/typelist_assoc_container.hpp \
+ ${pb_srcdir}/detail/typelist.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_append.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_apply.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_assoc_container_find.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_at_index.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_contains.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_filter.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_flatten.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_transform.hpp \
+ ${pb_srcdir}/detail/typelist/typelist_typelist_append.hpp \
+ ${pb_srcdir}/detail/types_traits.hpp \
+ ${pb_srcdir}/detail/type_utils.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/const_iterator.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/const_point_iterator.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/iterator.hpp \
+ ${pb_srcdir}/detail/unordered_iterator/point_iterator.hpp
ext_srcdir = ${glibcxx_srcdir}/include/ext
ext_builddir = ./ext
@@ -910,7 +992,7 @@ PCHFLAGS = -Winvalid-pch -Wno-deprecated -x c++-header $(CXXFLAGS)
# CLEANFILES and all-local are kept up-to-date.
allstamped = \
stamp-std stamp-bits stamp-c_base stamp-c_compatibility \
- stamp-backward stamp-ext stamp-assoc stamp-tr1 stamp-debug stamp-host
+ stamp-backward stamp-ext stamp-pb stamp-tr1 stamp-debug stamp-host
# List of all files that are created by explicit building, editing, or
@@ -1160,42 +1242,54 @@ stamp-ext: ${ext_headers}
# Have to deal with nested include directories, gah! Strip off source
# directory before making the link.
-# XXX check ${assoc_headers}
-stamp-assoc:
- @if [ ! -d "${assoc_builddir}" ]; then \
- mkdir -p ${assoc_subdirs} ;\
+# XXX check ${pb_headers}
+stamp-pb:
+ @if [ ! -d "${pb_builddir}" ]; then \
+ mkdir -p ${pb_subdirs} ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers1}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers1}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers2}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers2}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers3}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers3}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers4}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers4}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- @if [ ! -f stamp-assoc ]; then \
- cd ${assoc_builddir} && for h in ${assoc_headers5}; do \
- build_name=`echo $$h | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers5}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
$(LN_S) $$h $${build_name} || true ;\
done ;\
fi
- $(STAMP) stamp-assoc
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers6}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(LN_S) $$h $${build_name} || true ;\
+ done ;\
+ fi
+ @if [ ! -f stamp-pb ]; then \
+ cd ${pb_builddir} && for h in ${pb_headers7}; do \
+ build_name=`echo $$h | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(LN_S) $$h $${build_name} || true ;\
+ done ;\
+ fi
+ $(STAMP) stamp-pb
stamp-tr1: ${tr1_headers}
@if [ ! -d "${tr1_builddir}" ]; then \
@@ -1355,28 +1449,36 @@ install-headers:
$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${ext_builddir}
for file in ${ext_headers}; do \
$(INSTALL_DATA) $${file} $(DESTDIR)${gxx_include_dir}/${ext_builddir}; done
- $(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${assoc_builddir}
- for dir in ${assoc_subdirs}; do \
+ $(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${pb_builddir}
+ for dir in ${pb_subdirs}; do \
$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/$${dir} ; done
- for file in ${assoc_headers1}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers1}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
+ for file in ${pb_headers2}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
+ $(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
+ for file in ${pb_headers3}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers2}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers4}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers3}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers5}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers4}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers6}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
- for file in ${assoc_headers5}; do \
- install_base=$(DESTDIR)${gxx_include_dir}/${assoc_builddir} ; \
- relative_name=`echo $$file | sed -e "s|${assoc_srcdir}|.|g"` ;\
+ for file in ${pb_headers7}; do \
+ install_base=$(DESTDIR)${gxx_include_dir}/${pb_builddir} ; \
+ relative_name=`echo $$file | sed -e "s|${pb_srcdir}|.|g"` ;\
$(INSTALL_DATA) $${file} $${install_base}/$${relative_name} ; done
$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${tr1_builddir}
for file in ${tr1_headers}; do \
diff --git a/libstdc++-v3/include/ext/pb_assoc/assoc_cntnr.hpp b/libstdc++-v3/include/ext/pb_assoc/assoc_cntnr.hpp
deleted file mode 100644
index 741b93814b5..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/assoc_cntnr.hpp
+++ /dev/null
@@ -1,1590 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file assoc_cntnr.hpp
- * Contains associative containers.
- */
-
-#ifndef ASSOC_CNTNR_HPP
-#define ASSOC_CNTNR_HPP
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-namespace pb_assoc
-{
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class DS_Tag, \
- class Policy_Tl, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- Data, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- detail::assoc_cntnr_base< \
- Key, \
- Data, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>::type
-
-#define PB_ASSOC_DIRECT_BASE_C_DEC \
- detail::assoc_cntnr_base< \
- Key, \
- Data, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>::type
-
- template
- class basic_assoc_cntnr
- : public detail::assoc_cntnr_base::type
- {
- public:
- typedef typename Allocator::size_type size_type;
- typedef typename Allocator::difference_type difference_type;
- typedef DS_Tag ds_category;
- typedef data_enabled_ms_tag ms_category;
- typedef Allocator allocator;
-
- typedef
- typename allocator::template rebind<
- Key>::other::value_type
- key_type;
-
- typedef
- typename allocator::template rebind<
- Key>::other::reference
- key_reference;
-
- typedef
- typename allocator::template rebind<
- Key>::other::const_reference
- const_key_reference;
-
- typedef
- typename allocator::template rebind<
- Key>::other::pointer
- key_pointer;
-
- typedef
- typename allocator::template rebind<
- Key>::other::const_pointer
- const_key_pointer;
-
- typedef
- typename allocator::template rebind<
- Data>::other::value_type
- data_type;
-
- typedef
- typename allocator::template rebind<
- Data>::other::reference
- data_reference;
-
- typedef
- typename allocator::template rebind<
- Data>::other::const_reference
- const_data_reference;
-
- typedef
- typename allocator::template rebind<
- Data>::other::pointer
- data_pointer;
-
- typedef
- typename allocator::template rebind<
- Data>::other::const_pointer
- const_data_pointer;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::value_type
- value_type;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::reference
- reference;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::const_reference
- const_reference;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::pointer
- pointer;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::const_pointer
- const_pointer;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::const_find_iterator
- const_find_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::find_iterator find_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::const_iterator const_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::iterator iterator;
-
- public:
-
- virtual
- ~basic_assoc_cntnr();
-
- inline size_type
- size() const;
-
- inline size_type
- max_size() const;
-
- inline bool
- empty() const;
-
- inline static const_key_reference
- extract_key(const_reference r_val);
-
- inline std::pair
- insert(const_reference r_val);
-
- inline data_reference
- operator[](const_key_reference r_key);
-
- inline find_iterator
- find(const_key_reference r_key)
- {
- return (my_base::find(r_key));
- }
-
- inline const_find_iterator
- find(const_key_reference r_key) const
- {
- return (my_base::find(r_key));
- }
-
- inline const_data_reference
- operator[](const_key_reference r_key) const;
-
- inline size_type
- erase(const_key_reference r_key);
-
- template
- inline size_type
- erase_if(Pred prd);
-
- void
- clear();
-
- inline iterator
- begin();
-
- inline const_iterator
- begin() const;
-
- inline iterator
- end();
-
- inline const_iterator
- end() const;
-
- protected:
-
-#define PB_ASSOC_CLASS_NAME basic_assoc_cntnr
-
-#define PB_ASSOC_DIRECT_BASE_CAST_C_DEC \
- typename PB_ASSOC_DIRECT_BASE_C_DEC
-
-#include
-
-#undef PB_ASSOC_DIRECT_BASE_CAST_C_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
- private:
- typedef typename PB_ASSOC_BASE_C_DEC my_base;
-
- private:
- basic_assoc_cntnr&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
- };
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- class Cntnr, \
- class DS_Tag, \
- class Policy_Tl, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- compound_data_type< \
- Cntnr>, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>
-
-#define PB_ASSOC_DIRECT_BASE_C_DEC \
- detail::value_type_adapter< \
- Key, \
- compound_data_type< \
- Cntnr>, \
- DS_Tag, \
- Policy_Tl, \
- Allocator, \
- detail::mapping_level_imp< \
- compound_data_type< \
- Cntnr> >::value - 1>
-
-#define PB_ASSOC_BASE_C_DEC \
- detail::assoc_cntnr_base< \
- Key, \
- compound_data_type< \
- Cntnr>, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>::type
-
- template
- class basic_assoc_cntnr, DS_Tag, Policy_Tl, Allocator> : public PB_ASSOC_DIRECT_BASE_C_DEC
- {
- public:
- typedef typename Allocator::size_type size_type;
- typedef typename Allocator::difference_type difference_type;
- typedef DS_Tag ds_category;
- typedef compound_data_enabled_ms_tag ms_category;
- typedef Allocator allocator;
-
- typedef
- typename allocator::template rebind<
- Key>::other::value_type
- key_type;
-
- typedef
- typename allocator::template rebind<
- Key>::other::reference
- key_reference;
-
- typedef
- typename allocator::template rebind<
- Key>::other::const_reference
- const_key_reference;
-
- typedef
- typename allocator::template rebind<
- Key>::other::pointer
- key_pointer;
-
- typedef
- typename allocator::template rebind<
- Key>::other::const_pointer
- const_key_pointer;
-
- typedef
- typename allocator::template rebind<
- Cntnr>::other::value_type
- data_type;
-
- typedef
- typename allocator::template rebind<
- Cntnr>::other::reference
- data_reference;
-
- typedef
- typename allocator::template rebind<
- Cntnr>::other::const_reference
- const_data_reference;
-
- typedef
- typename allocator::template rebind<
- Cntnr>::other::pointer
- data_pointer;
-
- typedef
- typename allocator::template rebind<
- Cntnr>::other::const_pointer
- const_data_pointer;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::value_type
- value_type;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::reference
- reference;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::const_reference
- const_reference;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::pointer
- pointer;
-
- typedef
- typename allocator::template rebind<
- std::pair >::other::const_pointer
- const_pointer;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::const_find_iterator
- const_find_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::find_iterator find_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::const_iterator const_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::iterator iterator;
-
- template
- struct rebind
- {
- private:
- enum
- {
- mapping_level =
- detail::mapping_level_imp >::value
- };
-
- public:
- typedef
- detail::value_type_adapter<
- Key,
- compound_data_type<
- Cntnr>,
- DS_Tag,
- Policy_Tl,
- Allocator,
- mapping_level - Mapping_Level>
- other;
- };
-
- public:
-
- virtual
- ~basic_assoc_cntnr();
-
- inline size_type
- size() const;
-
- inline size_type
- max_size() const;
-
- inline bool
- empty() const;
-
- inline static const_key_reference
- extract_key(const_reference r_val);
-
- inline std::pair
- insert(const_reference r_val);
-
- inline data_reference
- operator[](const_key_reference r_key);
-
- inline find_iterator
- find(const_key_reference r_key)
- {
- return (my_base::find(r_key));
- }
-
- inline const_find_iterator
- find(const_key_reference r_key) const
- {
- return (my_base::find(r_key));
- }
-
- inline const_data_reference
- operator[](const_key_reference r_key) const;
-
- inline size_type
- erase(const_key_reference r_key);
-
- template
- inline size_type
- erase_if(Pred prd);
-
- void
- clear();
-
- inline iterator
- begin();
-
- inline const_iterator
- begin() const;
-
- inline iterator
- end();
-
- inline const_iterator
- end() const;
-
- protected:
-
-#define PB_ASSOC_CLASS_NAME basic_assoc_cntnr
-
-#define PB_ASSOC_DIRECT_BASE_CAST_C_DEC \
- typename PB_ASSOC_DIRECT_BASE_C_DEC
-
-#include
-
-#undef PB_ASSOC_DIRECT_BASE_CAST_C_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
- private:
- typedef typename PB_ASSOC_BASE_C_DEC my_base;
-
- private:
- basic_assoc_cntnr&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
- };
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template
-
-#define PB_ASSOC_CLASS_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- null_data_type, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- detail::assoc_cntnr_base< \
- Key, \
- null_data_type, \
- DS_Tag, \
- Policy_Tl, \
- Allocator>::type
-
- template
- class basic_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef typename Allocator::size_type size_type;
- typedef typename Allocator::difference_type difference_type;
- typedef DS_Tag ds_category;
- typedef basic_ms_tag ms_category;
- typedef Allocator allocator;
-
- typedef
- typename allocator::template rebind<
- Key>::other::value_type
- key_type;
-
- typedef
- typename allocator::template rebind<
- Key>::other::reference
- key_reference;
-
- typedef
- typename allocator::template rebind<
- Key>::other::const_reference
- const_key_reference;
-
- typedef
- typename allocator::template rebind<
- Key>::other::pointer
- key_pointer;
-
- typedef
- typename allocator::template rebind<
- Key>::other::const_pointer
- const_key_pointer;
-
- typedef
- typename allocator::template rebind<
- key_type>::other::value_type
- value_type;
-
- typedef
- typename allocator::template rebind<
- key_type>::other::const_reference
- reference;
-
- typedef
- typename allocator::template rebind<
- key_type>::other::const_reference
- const_reference;
-
- typedef
- typename allocator::template rebind<
- key_type>::other::const_pointer
- pointer;
-
- typedef
- typename allocator::template rebind::other::const_pointer
- const_pointer;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::const_find_iterator
- const_find_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::find_iterator find_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::const_iterator const_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::iterator iterator;
-
- public:
-
- virtual
- ~basic_assoc_cntnr();
-
- inline size_type
- size() const;
-
- inline size_type
- max_size() const;
-
- inline bool
- empty() const;
-
- inline static const_key_reference
- extract_key(const_reference r_val);
-
- inline std::pair
- insert(const_reference r_val);
-
- inline find_iterator
- find(const_key_reference r_key)
- { return (my_base::find(r_key)); }
-
- inline const_find_iterator
- find(const_key_reference r_key) const
- { return (my_base::find(r_key)); }
-
- inline size_type
- erase(const_key_reference r_key);
-
- template
- inline size_type
- erase_if(Pred prd);
-
- void
- clear();
-
- inline iterator
- begin();
-
- inline const_iterator
- begin() const;
-
- inline iterator
- end();
-
- inline const_iterator
- end() const;
-
- protected:
-
-#define PB_ASSOC_CLASS_NAME basic_assoc_cntnr
-
-#define PB_ASSOC_DIRECT_BASE_C_DEC PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_DIRECT_BASE_CAST_C_DEC \
- typename PB_ASSOC_DIRECT_BASE_C_DEC
-
-#include
-
-#undef PB_ASSOC_DIRECT_BASE_CAST_C_DEC
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
- private:
- typedef typename PB_ASSOC_BASE_C_DEC my_base;
-
- private:
- basic_assoc_cntnr&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
- };
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_TYPELIST_CHAIN1(X0) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN2(X0, X1) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN3(X0, X1, X2) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN4(X0, X1, X2, X3) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN5(X0, X1, X2, X3, X4) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN6(X0, X1, X2, X3, X4, X5) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN7(X0, X1, X2, X3, X4, X5, X6) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN8(X0, X1, X2, X3, X4, X5, X6, X7) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN9(X0, X1, X2, X3, X4, X5, X6, X7, X8) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN10(X0, X1, X2, X3, X4, X5, X6, X7, X8, X9) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN11(X0, X1, X2, X3, X4, X5, X6, X7, X8, X9, X10) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN12(X0, X1, X2, X3, X4, X5, X6, X7, X8, X9, X10, X11) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN13(X0, X1, X2, X3, X4, X5, X6, X7, X8, X9, X10, X11, X12) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN14(X0, X1, X2, X3, X4, X5, X6, X7, X8, X9, X10, X11, X12, X13) pb_assoc::detail::typelist_chain
-#define PB_ASSOC_TYPELIST_CHAIN15(X0, X1, X2, X3, X4, X5, X6, X7, X8, X9, X10, X11, X12, X13, X14) pb_assoc::detail::typelist_chain
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Hash_Fn, \
- class Eq_Fn, \
- class Resize_Policy, \
- bool Store_Hash, \
- class DS_Tag, \
- class Policy_TL, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- basic_hash_assoc_cntnr< \
- Key, \
- Data, \
- Hash_Fn, \
- Eq_Fn, \
- Resize_Policy, \
- Store_Hash, \
- DS_Tag, \
- Policy_TL, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- Data, \
- DS_Tag, \
- typename pb_assoc::detail::typelist_append< \
- pb_assoc::detail::typelist< \
- PB_ASSOC_TYPELIST_CHAIN4( Hash_Fn, Eq_Fn, Resize_Policy, pb_assoc::detail::int_to_type) >, \
- Policy_TL>::type, \
- Allocator>
-
- template
- class basic_hash_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef Hash_Fn hash_fn;
-
- typedef Eq_Fn eq_fn;
-
- typedef Resize_Policy resize_policy;
-
- enum
- {
- store_hash = Store_Hash
- };
-
- virtual
- ~basic_hash_assoc_cntnr();
-
- hash_fn&
- get_hash_fn();
-
- const hash_fn&
- get_hash_fn() const;
-
- eq_fn&
- get_eq_fn();
-
- const eq_fn&
- get_eq_fn() const;
-
- Resize_Policy&
- get_resize_policy();
-
- const resize_policy&
- get_resize_policy() const;
-
- protected:
-
- typedef typename Allocator::size_type size_type;
-
- virtual void
- do_resize(size_type new_size);
-
-#define PB_ASSOC_CLASS_NAME basic_hash_assoc_cntnr
-
-#define PB_ASSOC_DIRECT_BASE_C_DEC PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_DIRECT_BASE_CAST_C_DEC \
- PB_ASSOC_DIRECT_BASE_C_DEC
-
-#include
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
-
- basic_hash_assoc_cntnr&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
- };
-
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Hash_Fn, \
- class Eq_Fn, \
- class Comb_Hash_Fn, \
- class Resize_Policy, \
- bool Store_Hash, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- cc_hash_assoc_cntnr< \
- Key, \
- Data, \
- Hash_Fn, \
- Eq_Fn, \
- Comb_Hash_Fn, \
- Resize_Policy, \
- Store_Hash, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_hash_assoc_cntnr< \
- Key, \
- Data, \
- Hash_Fn, \
- Eq_Fn, \
- Resize_Policy, \
- Store_Hash, \
- cc_hash_ds_tag, \
- pb_assoc::detail::typelist< \
- PB_ASSOC_TYPELIST_CHAIN1( \
- Comb_Hash_Fn) >, \
- Allocator>
-
- template::type,
- class Eq_Fn = typename pb_assoc::detail::def_eq_fn::type,
- class Comb_Hash_Fn = pb_assoc::detail::def_comb_hash_fn::type,
- class Resize_Policy =
- typename pb_assoc::detail::def_resize_policy::type,
- bool Store_Hash = pb_assoc::detail::def_store_hash,
- class Allocator = std::allocator >
- class cc_hash_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef Comb_Hash_Fn comb_hash_fn;
-
- cc_hash_assoc_cntnr();
-
- cc_hash_assoc_cntnr(const Hash_Fn& r_hash_fn);
-
- cc_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn);
-
- cc_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn,
- const Comb_Hash_Fn& r_comb_hash_fn);
-
- cc_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn,
- const Comb_Hash_Fn& r_comb_hash_fn,
- const Resize_Policy& r_resize_policy);
-
- template
- cc_hash_assoc_cntnr(It first_it, It last_it);
-
- template
- cc_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn);
-
- template
- cc_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn,
- const Eq_Fn& r_eq_fn);
-
- template
- cc_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn, const Comb_Hash_Fn& r_comb_hash_fn);
-
- template
- cc_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn, const Comb_Hash_Fn& r_comb_hash_fn, const Resize_Policy& r_resize_policy);
-
- cc_hash_assoc_cntnr(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- virtual
- ~cc_hash_assoc_cntnr();
-
- PB_ASSOC_CLASS_C_DEC&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- swap(PB_ASSOC_CLASS_C_DEC& r_other);
-
- comb_hash_fn&
- get_comb_hash_fn();
-
- const comb_hash_fn&
- get_comb_hash_fn() const;
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
- };
-
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Hash_Fn, \
- class Eq_Fn, \
- class Comb_Probe_Fn, \
- class Probe_Fn, \
- class Resize_Policy, \
- bool Store_Hash, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- gp_hash_assoc_cntnr< \
- Key, \
- Data, \
- Hash_Fn, \
- Eq_Fn, \
- Comb_Probe_Fn, \
- Probe_Fn, \
- Resize_Policy, \
- Store_Hash, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_hash_assoc_cntnr< \
- Key, \
- Data, \
- Hash_Fn, \
- Eq_Fn, \
- Resize_Policy, \
- Store_Hash, \
- gp_hash_ds_tag, \
- pb_assoc::detail::typelist< \
- PB_ASSOC_TYPELIST_CHAIN2( Comb_Probe_Fn, Probe_Fn) >, \
- Allocator>
-
- template::type,
- class Eq_Fn = typename pb_assoc::detail::def_eq_fn::type,
- class Comb_Probe_Fn = pb_assoc::detail::def_comb_hash_fn::type,
- class Probe_Fn = typename detail::def_probe_fn::type,
- class Resize_Policy =
- typename pb_assoc::detail::def_resize_policy::type,
-
- bool Store_Hash = pb_assoc::detail::def_store_hash,
- class Allocator = std::allocator >
- class gp_hash_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef Comb_Probe_Fn comb_probe_fn;
- typedef Probe_Fn probe_fn;
-
- gp_hash_assoc_cntnr();
-
- gp_hash_assoc_cntnr(const Hash_Fn& r_hash_fn);
-
- gp_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn);
-
- gp_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn,
- const Comb_Probe_Fn& r_comb_probe_fn);
-
- gp_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn,
- const Comb_Probe_Fn& r_comb_probe_fn,
- const Probe_Fn& r_probe_fn);
-
- gp_hash_assoc_cntnr(const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn,
- const Comb_Probe_Fn& r_comb_probe_fn,
- const Probe_Fn& r_probe_fn,
- const Resize_Policy& r_resize_policy);
-
- template
- gp_hash_assoc_cntnr(It first_it, It last_it);
-
- template
- gp_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn);
-
- template
- gp_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn);
-
- template
- gp_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn, const Comb_Probe_Fn& r_comb_probe_fn);
-
- template
- gp_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn, const Comb_Probe_Fn& r_comb_probe_fn, const Probe_Fn& r_probe_fn);
-
- template
- gp_hash_assoc_cntnr(It first_it, It last_it, const Hash_Fn& r_hash_fn, const Eq_Fn& r_eq_fn, const Comb_Probe_Fn& r_comb_probe_fn, const Probe_Fn& r_probe_fn, const Resize_Policy& r_resize_policy);
-
- gp_hash_assoc_cntnr(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- virtual
- ~gp_hash_assoc_cntnr();
-
- PB_ASSOC_CLASS_C_DEC&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- swap(PB_ASSOC_CLASS_C_DEC& r_other);
-
- comb_probe_fn&
- get_comb_probe_fn();
-
- const comb_probe_fn&
- get_comb_probe_fn() const;
-
- probe_fn&
- get_probe_fn();
-
- const probe_fn&
- get_probe_fn() const;
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
- };
-
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Cmp_Fn, \
- class DS_Tag, \
- class Node_Updator, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- basic_tree_assoc_cntnr< \
- Key, \
- Data, \
- Cmp_Fn, \
- DS_Tag, \
- Node_Updator, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- Data, \
- DS_Tag, \
- pb_assoc::detail::typelist< \
- PB_ASSOC_TYPELIST_CHAIN2( Cmp_Fn, Node_Updator) >, \
- Allocator>
-
- template
- class basic_tree_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef typename Allocator::size_type size_type;
-
- typedef
- typename Allocator::template rebind<
- Key>::other::const_reference
- const_key_reference;
-
- typedef Cmp_Fn cmp_fn;
-
- typedef Node_Updator node_updator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::const_iterator const_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::iterator iterator;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::const_reverse_iterator
- const_reverse_iterator;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::reverse_iterator
- reverse_iterator;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::const_node_iterator
- const_node_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::node_iterator node_iterator;
-
- virtual
- ~basic_tree_assoc_cntnr();
-
- cmp_fn&
- get_cmp_fn();
-
- const cmp_fn&
- get_cmp_fn() const;
-
- node_updator&
- get_node_updator();
-
- const node_updator&
- get_node_updator() const;
-
- inline size_type
- erase(const_key_reference r_key);
-
- inline iterator
- erase(iterator it);
-
- inline reverse_iterator
- erase(reverse_iterator it)
- {
- return (my_base::erase(it));
- }
-
- inline reverse_iterator
- rbegin()
- {
- return (my_base::rbegin());
- }
-
- inline const_reverse_iterator
- rbegin() const
- {
- return (my_base::rbegin());
- }
-
- inline reverse_iterator
- rend()
- {
- return (my_base::rend());
- }
-
- inline const_reverse_iterator
- rend() const
- {
- return (my_base::rend());
- }
-
- inline node_iterator
- node_begin()
- {
- return (my_base::node_begin());
- }
-
- inline const_node_iterator
- node_begin() const
- {
- return (my_base::node_begin());
- }
-
- inline node_iterator
- node_end()
- {
- return (my_base::node_end());
- }
-
- inline const_node_iterator
- node_end() const
- {
- return (my_base::node_end());
- }
-
- void
- join(PB_ASSOC_CLASS_C_DEC& r_other);
-
- inline void
- split(const_key_reference r_key, PB_ASSOC_CLASS_C_DEC& r_other);
-
- protected:
-
-#define PB_ASSOC_CLASS_NAME basic_tree_assoc_cntnr
-
-#define PB_ASSOC_DIRECT_BASE_C_DEC PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_DIRECT_BASE_CAST_C_DEC \
- PB_ASSOC_DIRECT_BASE_C_DEC
-
-#include
-
-#undef PB_ASSOC_DIRECT_BASE_CAST_C_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
- };
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Cmp_Fn, \
- class Node_Updator, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- basic_tree_assoc_cntnr< \
- Key, \
- Data, \
- Cmp_Fn, \
- ov_tree_ds_tag, \
- Node_Updator, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- Data, \
- ov_tree_ds_tag, \
- pb_assoc::detail::typelist< \
- PB_ASSOC_TYPELIST_CHAIN2( Cmp_Fn, Node_Updator) >, \
- Allocator>
-
- template
- class basic_tree_assoc_cntnr
- : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef typename Allocator::size_type size_type;
-
- typedef
- typename Allocator::template rebind<
- Key>::other::const_reference
- const_key_reference;
-
- typedef Cmp_Fn cmp_fn;
-
- typedef Node_Updator node_updator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::const_iterator const_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::iterator iterator;
-
- typedef
- typename PB_ASSOC_BASE_C_DEC::const_node_iterator
- const_node_iterator;
-
- typedef typename PB_ASSOC_BASE_C_DEC::node_iterator node_iterator;
-
- virtual
- ~basic_tree_assoc_cntnr();
-
- cmp_fn&
- get_cmp_fn();
-
- const cmp_fn&
- get_cmp_fn() const;
-
- node_updator&
- get_node_updator();
-
- const node_updator&
- get_node_updator() const;
-
- inline size_type
- erase(const_key_reference r_key);
-
- inline iterator
- erase(iterator it);
-
- inline node_iterator
- node_begin()
- {
- return (my_base::node_begin());
- }
-
- inline const_node_iterator
- node_begin() const
- {
- return (my_base::node_begin());
- }
-
- inline node_iterator
- node_end()
- {
- return (my_base::node_end());
- }
-
- inline const_node_iterator
- node_end() const
- {
- return (my_base::node_end());
- }
-
- void
- join(PB_ASSOC_CLASS_C_DEC& r_other);
-
- inline void
- split(const_key_reference r_key, PB_ASSOC_CLASS_C_DEC& r_other);
-
- protected:
-
-#define PB_ASSOC_CLASS_NAME basic_tree_assoc_cntnr
-
-#define PB_ASSOC_DIRECT_BASE_C_DEC PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_DIRECT_BASE_CAST_C_DEC \
- PB_ASSOC_DIRECT_BASE_C_DEC
-
-#include
-
-#undef PB_ASSOC_DIRECT_BASE_CAST_C_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
-#undef PB_ASSOC_DIRECT_BASE_C_DEC
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
- };
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Cmp_Fn, \
- class DS_Tag, \
- class Node_Updator, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- tree_assoc_cntnr< \
- Key, \
- Data, \
- Cmp_Fn, \
- DS_Tag, \
- Node_Updator, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_tree_assoc_cntnr< \
- Key, \
- Data, \
- Cmp_Fn, \
- DS_Tag, \
- Node_Updator, \
- Allocator>
-
- template,
- typename DS_Tag = rb_tree_ds_tag,
- typename Node_Updator = pb_assoc::detail::def_node_updator,
- typename Allocator = std::allocator >
- class tree_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- typedef Cmp_Fn cmp_fn;
- typedef Node_Updator node_updator;
-
- public:
- tree_assoc_cntnr();
- tree_assoc_cntnr(const cmp_fn& r_cmp_fn);
- tree_assoc_cntnr(const cmp_fn& r_cmp_fn, const Node_Updator&r);
-
- template
- tree_assoc_cntnr(It first_it, It last_it);
-
- template
- tree_assoc_cntnr(It first_it, It last_it, const cmp_fn& r_cmp_fn);
-
- template
- tree_assoc_cntnr(It, It, const cmp_fn&, const Node_Updator&);
-
- tree_assoc_cntnr(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- virtual
- ~tree_assoc_cntnr();
-
- PB_ASSOC_CLASS_C_DEC&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- swap(PB_ASSOC_CLASS_C_DEC& r_other);
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
- };
-
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Eq_Fn, \
- class Update_Policy, \
- class Allocator>
-
-#define PB_ASSOC_CLASS_C_DEC \
- lu_assoc_cntnr< \
- Key, \
- Data, \
- Eq_Fn, \
- Update_Policy, \
- Allocator>
-
-#define PB_ASSOC_BASE_C_DEC \
- basic_assoc_cntnr< \
- Key, \
- Data, \
- lu_ds_tag, \
- pb_assoc::detail::typelist< \
- PB_ASSOC_TYPELIST_CHAIN2( Eq_Fn, Update_Policy) >, \
- Allocator>
-
- template::type,
- typename Update_Policy = pb_assoc::detail::def_update_policy::type,
- typename Allocator = std::allocator >
- class lu_assoc_cntnr : public PB_ASSOC_BASE_C_DEC
- {
- public:
- typedef Eq_Fn eq_fn;
- typedef Allocator allocator;
- typedef Update_Policy update_policy;
-
- lu_assoc_cntnr();
- lu_assoc_cntnr(const Eq_Fn& r_eq_fn);
- lu_assoc_cntnr(const Eq_Fn& r_eq_fn, const Update_Policy& r_update_policy);
-
- template
- lu_assoc_cntnr(It first_it, It last_it);
-
- template
- lu_assoc_cntnr(It first_it, It last_it, const Eq_Fn& r_eq_fn);
-
- template
- lu_assoc_cntnr(It, It, const Eq_Fn&, const Update_Policy&);
-
- lu_assoc_cntnr(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- virtual
- ~lu_assoc_cntnr();
-
- PB_ASSOC_CLASS_C_DEC&
- operator=(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- swap(PB_ASSOC_CLASS_C_DEC& r_other);
-
- eq_fn&
- get_eq_fn();
-
- const eq_fn&
- get_eq_fn() const;
-
- update_policy&
- get_update_policy();
-
- const update_policy&
- get_update_policy() const;
-
- private:
- typedef PB_ASSOC_BASE_C_DEC my_base;
- };
-
-#include
-#include
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_BASE_C_DEC
-
-#undef PB_ASSOC_TYPELIST_CHAIN1
-#undef PB_ASSOC_TYPELIST_CHAIN2
-#undef PB_ASSOC_TYPELIST_CHAIN3
-#undef PB_ASSOC_TYPELIST_CHAIN4
-#undef PB_ASSOC_TYPELIST_CHAIN5
-#undef PB_ASSOC_TYPELIST_CHAIN6
-#undef PB_ASSOC_TYPELIST_CHAIN7
-#undef PB_ASSOC_TYPELIST_CHAIN8
-#undef PB_ASSOC_TYPELIST_CHAIN9
-#undef PB_ASSOC_TYPELIST_CHAIN10
-#undef PB_ASSOC_TYPELIST_CHAIN11
-#undef PB_ASSOC_TYPELIST_CHAIN12
-#undef PB_ASSOC_TYPELIST_CHAIN13
-#undef PB_ASSOC_TYPELIST_CHAIN14
-#undef PB_ASSOC_TYPELIST_CHAIN15
-
-} // namespace pb_assoc
-
-#endif // #ifndef ASSOC_CNTNR_HPP
diff --git a/libstdc++-v3/include/ext/pb_assoc/data_type.hpp b/libstdc++-v3/include/ext/pb_assoc/data_type.hpp
deleted file mode 100644
index b670a0088a3..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/data_type.hpp
+++ /dev/null
@@ -1,60 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file data_tye.hpp
- * Contains a traits class of types used by containers.
- */
-
-#ifndef DATA_TYPE_HPP
-#define DATA_TYPE_HPP
-
-namespace pb_assoc
-{
- struct null_data_type
- { };
-
- template
- struct compound_data_type
- {
- typedef Cntnr cntnr;
- };
-} // namespace pb_assoc
-
-#endif // #ifndef DATA_TYPE_HPP
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/assoc_cntnr_base.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/assoc_cntnr_base.hpp
deleted file mode 100644
index 4e441b81a99..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/assoc_cntnr_base.hpp
+++ /dev/null
@@ -1,346 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file assoc_cntnr_base.hpp
- * Contains an associative container dispatching base.
- */
-
-#ifndef ASSOC_CNTNR_BASE_HPP
-#define ASSOC_CNTNR_BASE_HPP
-
-#include
-
-#define PB_ASSOC_DATA_TRUE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#define PB_ASSOC_DATA_FALSE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_FALSE_INDICATOR
-
-#define PB_ASSOC_DATA_TRUE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#define PB_ASSOC_DATA_FALSE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_FALSE_INDICATOR
-
-#define PB_ASSOC_DATA_TRUE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#define PB_ASSOC_DATA_FALSE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_FALSE_INDICATOR
-
-#define PB_ASSOC_DATA_TRUE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#define PB_ASSOC_DATA_FALSE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_FALSE_INDICATOR
-
-#define PB_ASSOC_DATA_TRUE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#define PB_ASSOC_DATA_FALSE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_FALSE_INDICATOR
-
-#define PB_ASSOC_DATA_TRUE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#define PB_ASSOC_DATA_FALSE_INDICATOR
-#include
-#undef PB_ASSOC_DATA_FALSE_INDICATOR
-
-namespace pb_assoc
-{
-
- namespace detail
- {
-
- template
- struct assoc_cntnr_base;
-
- template
- struct assoc_cntnr_base<
- Key,
- Data,
- lu_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- lu_map_data_<
- Key,
- Data,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- null_data_type,
- lu_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- lu_map_no_data_<
- Key,
- null_data_type,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- Data,
- rb_tree_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- rb_tree_data_<
- Key,
- Data,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- null_data_type,
- rb_tree_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- rb_tree_no_data_<
- Key,
- null_data_type,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- Data,
- splay_tree_ds_tag,
- Policy_Tl,
- Allocator>
-
- {
- typedef
- splay_tree_data_<
- Key,
- Data,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- null_data_type,
- splay_tree_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- splay_tree_no_data_<
- Key,
- null_data_type,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- Data,
- ov_tree_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- ov_tree_data_<
- Key,
- Data,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- null_data_type,
- ov_tree_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- ov_tree_no_data_<
- Key,
- null_data_type,
- typename typelist_at_index::type,
- Allocator,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- Data,
- cc_hash_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- cc_ht_map_data_<
- Key,
- Data,
- typename typelist_at_index::type,
- typename typelist_at_index::type,
- Allocator,
- typelist_at_index::type::value,
- typename typelist_at_index::type,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- null_data_type,
- cc_hash_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- cc_ht_map_no_data_<
- Key,
- null_data_type,
- typename typelist_at_index::type,
- typename typelist_at_index::type,
- Allocator,
- typelist_at_index::type::value,
- typename typelist_at_index::type,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- Data,
- gp_hash_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- gp_ht_map_data_<
- Key,
- Data,
- typename typelist_at_index::type,
- typename typelist_at_index::type,
- Allocator,
- typelist_at_index::type::value,
- typename typelist_at_index::type,
- typename typelist_at_index::type,
- typename typelist_at_index::type>
- type;
- };
-
- template
- struct assoc_cntnr_base<
- Key,
- null_data_type,
- gp_hash_ds_tag,
- Policy_Tl,
- Allocator>
- {
- typedef
- gp_ht_map_no_data_<
- Key,
- null_data_type,
- typename typelist_at_index::type,
- typename typelist_at_index::type,
- Allocator,
- typelist_at_index::type::value,
- typename typelist_at_index::type,
- typename typelist_at_index::type,
- typename typelist_at_index::type>
- type;
- };
-
- } // namespace detail
-
-} // namespace pb_assoc
-
-#endif // #ifndef ASSOC_CNTNR_BASE_HPP
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp
deleted file mode 100644
index a0dd0898bfb..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructor_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,164 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructor_destructor_fn_imps.hpp
- * Contains implementations of constructors, destructors,
- * and related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr()
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2, T3 t3) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2, t3)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2, T3 t3, T4 t4) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2, t3, t4)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2, T3 t3, T4 t4, T5 t5) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2, t3, t4, t5)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2, t3, t4, t5, t6)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2, t3, t4, t5, t6, t7)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(T0 t0, T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8) :
- PB_ASSOC_DIRECT_BASE_C_DEC(t0, t1, t2, t3, t4, t5, t6, t7, t8)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-inline
-PB_ASSOC_CLASS_C_DEC::
-basic_assoc_cntnr(const PB_ASSOC_CLASS_C_DEC& r_other) :
- PB_ASSOC_DIRECT_BASE_C_DEC((const PB_ASSOC_DIRECT_BASE_C_DEC& )r_other)
-{ }
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~basic_assoc_cntnr()
-{ }
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp
deleted file mode 100644
index 5cd12513c2b..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/constructors_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,48 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructors_destructor_fn_imps.hpp
- * Contains constructors and destructor implementation.
- */
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~basic_assoc_cntnr()
-{ }
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_extract_key.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_extract_key.hpp
deleted file mode 100644
index 1c7747edaa4..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_extract_key.hpp
+++ /dev/null
@@ -1,51 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file d_extract_key.hpp
- * Contains implementations of info related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_key_reference
-PB_ASSOC_CLASS_C_DEC::
-extract_key(const_reference r_val)
-{
- return (r_val.first);
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_find_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_find_fn_imps.hpp
deleted file mode 100644
index 30b03281d19..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_find_fn_imps.hpp
+++ /dev/null
@@ -1,51 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file d_find_fn_imps.hpp
- * Contains implementations of gp_ht_maps's find related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_data_reference
-PB_ASSOC_CLASS_C_DEC::
-operator[](const_key_reference r_key) const
-{
- return (my_base::const_subscript_imp(r_key));
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp
deleted file mode 100644
index 4193589d3eb..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/d_insert_fn_imps.hpp
+++ /dev/null
@@ -1,51 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file d_insert_fn_imps.hpp
- * Contains implementations of gp_ht_maps's erase related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::data_reference
-PB_ASSOC_CLASS_C_DEC::
-operator[](const_key_reference r_key)
-{
- return (my_base::subscript_imp(r_key));
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/erase_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/erase_fn_imps.hpp
deleted file mode 100644
index e22bc264559..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/erase_fn_imps.hpp
+++ /dev/null
@@ -1,68 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file erase_fn_imps.hpp
- * Contains implementations of gp_ht_maps's erase related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::size_type
-PB_ASSOC_CLASS_C_DEC::
-erase(const_key_reference r_key)
-{
- return (my_base::erase(r_key));
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-clear()
-{
- return (my_base::clear());
-}
-
-PB_ASSOC_CLASS_T_DEC
-template
-inline typename PB_ASSOC_CLASS_C_DEC::size_type
-PB_ASSOC_CLASS_C_DEC::
-erase_if(Pred pred)
-{
- return (my_base::erase_if(pred));
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/extract_key.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/extract_key.hpp
deleted file mode 100644
index 6806d0b89e7..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/extract_key.hpp
+++ /dev/null
@@ -1,51 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file extract_key.hpp
- * Contains implementations of info related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_key_reference
-PB_ASSOC_CLASS_C_DEC::
-extract_key(const_reference r_val)
-{
- return (r_val);
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/info_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/info_fn_imps.hpp
deleted file mode 100644
index 7467b05fb26..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/info_fn_imps.hpp
+++ /dev/null
@@ -1,67 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file info_fn_imps.hpp
- * Contains implementations of info related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::size_type
-PB_ASSOC_CLASS_C_DEC::
-size() const
-{
- return (my_base::size());
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::size_type
-PB_ASSOC_CLASS_C_DEC::
-max_size() const
-{
- return (my_base::max_size());
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline bool
-PB_ASSOC_CLASS_C_DEC::
-empty() const
-{
- return (my_base::empty());
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/insert_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/insert_fn_imps.hpp
deleted file mode 100644
index c8edc7eb95c..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/insert_fn_imps.hpp
+++ /dev/null
@@ -1,51 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file insert_fn_imps.hpp
- * Contains implementations of gp_ht_maps's erase related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline std::pair
-PB_ASSOC_CLASS_C_DEC::
-insert(const_reference r_value)
-{
- return (my_base::insert(r_value));
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/iterators_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/iterators_fn_imps.hpp
deleted file mode 100644
index 3bd1642c190..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_assoc_cntnr/iterators_fn_imps.hpp
+++ /dev/null
@@ -1,76 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file iterators_fn_imps.hpp
- * Contains implementations of gp_ht_map_'s iterators related functions, e.g.,
- * begin().
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::iterator
-PB_ASSOC_CLASS_C_DEC::
-begin()
-{
- return (my_base::begin());
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::iterator
-PB_ASSOC_CLASS_C_DEC::
-end()
-{
- return (my_base::end());
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_iterator
-PB_ASSOC_CLASS_C_DEC::
-begin() const
-{
- return (my_base::begin());
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_iterator
-PB_ASSOC_CLASS_C_DEC::
-end() const
-{
- return (my_base::end());
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp
deleted file mode 100644
index da0be878a84..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/constructor_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,50 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructor_destructor_fn_imps.hpp
- * Contains implementations of cc_ht's constructors, destructor,
- * and related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~PB_ASSOC_CLASS_NAME()
-{ }
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/constructors_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/constructors_destructor_fn_imps.hpp
deleted file mode 100644
index 48180a1744b..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/constructors_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,50 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructor_destructor_fn_imps.hpp
- * Contains implementations of cc_ht's constructors, destructor,
- * and related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~basic_hash_assoc_cntnr()
-{ }
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/resize_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/resize_fn_imps.hpp
deleted file mode 100644
index c5dd7143860..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_hash_assoc_cntnr/resize_fn_imps.hpp
+++ /dev/null
@@ -1,51 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file resize_fn_imps.hpp
- * Contains implementations of resize functions
- */
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-do_resize(size_type new_size)
-{
- return (my_base::do_resize(new_size));
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/constructor_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/constructor_destructor_fn_imps.hpp
deleted file mode 100644
index c5d2d01626e..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/constructor_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,50 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructor_destructor_fn_imps.hpp
- * Contains implementations of cc_ht's constructors, destructor,
- * and related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~basic_tree_assoc_cntnr()
-{ }
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/constructors_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/constructors_destructor_fn_imps.hpp
deleted file mode 100644
index c5d2d01626e..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/constructors_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,50 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructor_destructor_fn_imps.hpp
- * Contains implementations of cc_ht's constructors, destructor,
- * and related functions.
- */
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~basic_tree_assoc_cntnr()
-{ }
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/erase_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/erase_fn_imps.hpp
deleted file mode 100644
index b91511ce8d2..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/erase_fn_imps.hpp
+++ /dev/null
@@ -1,60 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file erase_fn_imps.hpp
- * Contains implementations of rb_tree's find related functions,
- * common to all tree container types.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::size_type
-PB_ASSOC_CLASS_C_DEC::
-erase(const_key_reference r_key)
-{
- return (my_base::erase(r_key));
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::iterator
-PB_ASSOC_CLASS_C_DEC::
-erase(iterator it)
-{
- return (my_base::erase(it));
-}
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/node_iteration_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/node_iteration_fn_imps.hpp
deleted file mode 100644
index d872d3df8a6..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/node_iteration_fn_imps.hpp
+++ /dev/null
@@ -1,44 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file node_iteration_fn_imps.hpp
- * Contains a rb_tree set implementation.
- */
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/policy_access_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/policy_access_fn_imps.hpp
deleted file mode 100644
index 7c71b6e0e13..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/policy_access_fn_imps.hpp
+++ /dev/null
@@ -1,76 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file policy_access_fn_imps.hpp
- * Contains implementation of rb trees
- */
-
-PB_ASSOC_CLASS_T_DEC
-Cmp_Fn&
-PB_ASSOC_CLASS_C_DEC::
-get_cmp_fn()
-{
- return (*this);
-}
-
-PB_ASSOC_CLASS_T_DEC
-const Cmp_Fn&
-PB_ASSOC_CLASS_C_DEC::
-get_cmp_fn() const
-{
- return (*this);
-}
-
-PB_ASSOC_CLASS_T_DEC
-Node_Updator&
-PB_ASSOC_CLASS_C_DEC::
-get_node_updator()
-{
- return (*this);
-}
-
-PB_ASSOC_CLASS_T_DEC
-const Node_Updator&
-PB_ASSOC_CLASS_C_DEC::
-get_node_updator() const
-{
- return (*this);
-}
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/r_erase_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/r_erase_fn_imps.hpp
deleted file mode 100644
index f6f13e1dbbe..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/r_erase_fn_imps.hpp
+++ /dev/null
@@ -1,44 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file erase_fn_imps.hpp
- * Contains implementations of rb_tree's find related functions,
- * common to all tree container types.
- */
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/r_range_iteration_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/r_range_iteration_fn_imps.hpp
deleted file mode 100644
index bdeb1d352bb..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/r_range_iteration_fn_imps.hpp
+++ /dev/null
@@ -1,43 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file range_iteration_fn_imps.hpp
- * Contains a rb_tree set implementation.
- */
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/range_iteration_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/range_iteration_fn_imps.hpp
deleted file mode 100644
index bdeb1d352bb..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/range_iteration_fn_imps.hpp
+++ /dev/null
@@ -1,43 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file range_iteration_fn_imps.hpp
- * Contains a rb_tree set implementation.
- */
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/split_join_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/split_join_fn_imps.hpp
deleted file mode 100644
index b8c46562a9b..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/basic_tree_assoc_cntnr/split_join_fn_imps.hpp
+++ /dev/null
@@ -1,60 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file split_join_fn_imps.hpp
- * Contains implementation of rb trees
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline void
-PB_ASSOC_CLASS_C_DEC::
-join(PB_ASSOC_CLASS_C_DEC& r_other)
-{
- return (my_base::join(r_other));
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline void
-PB_ASSOC_CLASS_C_DEC::
-split(const_key_reference r_key, PB_ASSOC_CLASS_C_DEC& r_other)
-{
- my_base::split(r_key, r_other);
-}
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/bin_search_tree_.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/bin_search_tree_.hpp
deleted file mode 100644
index b450f539807..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/bin_search_tree_.hpp
+++ /dev/null
@@ -1,525 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/*
- * @file bin_search_tree_.hpp
- * Contains an implementation class for bin_search_tree_.
- */
-/*
- * This implementation uses an idea from the SGI STL (using a "header" node
- * which is needed for efficient iteration).
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-namespace pb_assoc
-{
-
- namespace detail
- {
-
-#ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-#define PB_ASSOC_DBG_ASSERT(X) assert(X)
-#define PB_ASSOC_DBG_VERIFY(X) assert(X)
-#define PB_ASSOC_DBG_ONLY(X) X
-#else // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-#define PB_ASSOC_DBG_ASSERT(X)
-#define PB_ASSOC_DBG_VERIFY(X) {if((X)==0);}
-#define PB_ASSOC_DBG_ONLY(X) ;
-#endif // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-
-#define PB_ASSOC_CLASS_T_DEC \
- template< \
- typename Key, \
- typename Data, \
- class Node, \
- class Cmp_Fn, \
- class Allocator, \
- class Node_Updator>
-
-#ifdef PB_ASSOC_DATA_TRUE_INDICATOR
-#define PB_ASSOC_CLASS_NAME \
- bin_search_tree_data_
-#endif // #ifdef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#ifdef PB_ASSOC_DATA_FALSE_INDICATOR
-#define PB_ASSOC_CLASS_NAME \
- bin_search_tree_no_data_
-#endif // #ifdef PB_ASSOC_DATA_FALSE_INDICATOR
-
-#define PB_ASSOC_CLASS_C_DEC \
- PB_ASSOC_CLASS_NAME< \
- Key, \
- Data, \
- Node, \
- Cmp_Fn, \
- Allocator, \
- Node_Updator>
-
-#define PB_ASSOC_TYPES_TRAITS_C_DEC \
- pb_assoc::detail::types_traits< \
- Key, \
- Data, \
- Allocator>
-
-#ifdef PB_ASSOC_USE_MAP_DEBUG_BASE
-#define PB_ASSOC_MAP_DEBUG_BASE_C_DEC \
- pb_assoc::detail::map_debug_base< \
- Key, \
- eq_by_less >
-#endif // #ifdef PB_ASSOC_USE_MAP_DEBUG_BASE
-
-#ifdef PB_ASSOC_DATA_TRUE_INDICATOR
-#define PB_ASSOC_V2F(X) (X).first
-#define PB_ASSOC_V2S(X) (X).second
-#define PB_ASSOC_EP2VP(X)& ((X)->m_value)
-#endif // #ifdef PB_ASSOC_DATA_TRUE_INDICATOR
-
-#ifdef PB_ASSOC_DATA_FALSE_INDICATOR
-#define PB_ASSOC_V2F(X) (X)
-#define PB_ASSOC_V2S(X) Mapped_Data()
-#define PB_ASSOC_EP2VP(X)& ((X)->m_value.first)
-#endif // #ifdef PB_ASSOC_DATA_FALSE_INDICATOR
-
- template
- class PB_ASSOC_CLASS_NAME :
-#ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
- protected PB_ASSOC_MAP_DEBUG_BASE_C_DEC,
-#endif // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
- protected Cmp_Fn,
- public PB_ASSOC_TYPES_TRAITS_C_DEC,
- public Node_Updator
- {
-
- protected:
-
- typedef typename Allocator::size_type size_type;
-
- typedef
- typename PB_ASSOC_TYPES_TRAITS_C_DEC::const_key_reference
- const_key_reference;
-
- typedef typename PB_ASSOC_TYPES_TRAITS_C_DEC::data_type data_type;
-
- typedef
- typename PB_ASSOC_TYPES_TRAITS_C_DEC::data_reference
- data_reference;
-
- typedef
- typename PB_ASSOC_TYPES_TRAITS_C_DEC::const_data_reference
- const_data_reference;
-
- typedef typename PB_ASSOC_TYPES_TRAITS_C_DEC::value_type value_type;
-
- typedef typename PB_ASSOC_TYPES_TRAITS_C_DEC::pointer pointer;
-
- typedef
- typename PB_ASSOC_TYPES_TRAITS_C_DEC::const_pointer
- const_pointer;
-
- typedef typename PB_ASSOC_TYPES_TRAITS_C_DEC::reference reference;
-
- typedef
- typename PB_ASSOC_TYPES_TRAITS_C_DEC::const_reference
- const_reference;
-
- typedef PB_ASSOC_TYPES_TRAITS_C_DEC my_traits_base;
-
- typedef Node node;
-
- typedef
- pb_assoc::detail::cond_dealtor<
- node,
- Allocator>
- cond_dealtor_t;
-
- typedef
- typename Allocator::template rebind::other
- node_allocator;
-
- typedef typename node_allocator::value_type node_type;
-
- typedef typename node_allocator::pointer node_pointer;
-
- typedef value_type mapped_value_type;
-
- typedef reference mapped_reference;
-
- typedef const_reference const_mapped_reference;
-
- typedef pointer mapped_pointer;
-
- typedef const_pointer const_mapped_pointer;
-
-#include
-
- typedef const_it_ const_find_iterator;
-
- typedef it_ find_iterator;
-
- typedef const_find_iterator const_iterator;
-
- typedef find_iterator iterator;
-
- typedef const_it_ const_reverse_iterator;
-
- typedef it_ reverse_iterator;
-
-#include
-
- typedef const_node_it_ const_node_iterator;
-
- typedef node_it_ node_iterator;
-
- typedef Cmp_Fn cmp_fn;
-
- typedef Allocator allocator;
-
- private:
-
-#ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
- typedef PB_ASSOC_MAP_DEBUG_BASE_C_DEC my_map_debug_base;
-#endif // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-
- protected:
-
- PB_ASSOC_CLASS_NAME();
-
- PB_ASSOC_CLASS_NAME(const Cmp_Fn& r_cmp_fn);
-
- PB_ASSOC_CLASS_NAME(const Cmp_Fn& r_cmp_fn, const Node_Updator& r_updator);
-
- PB_ASSOC_CLASS_NAME(const PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- swap(PB_ASSOC_CLASS_C_DEC& r_other);
-
- ~PB_ASSOC_CLASS_NAME();
-
- void
- initialize_min_max();
-
- template
- bool
- cmp_with_other(const Other_Map_Type& r_other) const;
-
- inline bool
- empty() const;
-
- inline size_type
- size() const;
-
- inline size_type
- max_size() const;
-
- Cmp_Fn&
- get_cmp_fn();
-
- const Cmp_Fn&
- get_cmp_fn() const;
-
- inline std::pair
- insert_leaf(const_reference r_value);
-
- inline find_iterator
- lower_bound(const_key_reference r_key);
-
- inline const_find_iterator
- lower_bound(const_key_reference r_key) const;
-
- inline find_iterator
- upper_bound(const_key_reference r_key);
-
- inline const_find_iterator
- upper_bound(const_key_reference r_key) const;
-
- inline find_iterator
- find(const_key_reference r_key);
-
- inline const_find_iterator
- find(const_key_reference r_key) const;
-
- inline void
- update_min_max_for_erased_node(node_pointer p_nd);
-
- inline void
- actual_erase_node(node_pointer p_nd);
-
- void
- clear();
-
- inline void
- rotate_left(node_pointer p_x);
-
- inline void
- rotate_right(node_pointer p_y);
-
- inline void
- rotate_parent(node_pointer p_nd);
-
- inline void
- apply_update(node_pointer p_nd, pb_assoc::null_node_updator* );
-
- template
- inline void
- apply_update(node_pointer p_nd, Node_Updator_* p_updator);
-
- template
- inline void
- update_to_top(node_pointer p_nd, Node_Updator_* p_updator);
-
- inline void
- update_to_top(node_pointer p_nd, pb_assoc::null_node_updator* );
-
- inline iterator
- begin();
-
- inline const_iterator
- begin() const;
-
- inline iterator
- find_end();
-
- inline const_iterator
- find_end() const;
-
- inline iterator
- end();
-
- inline const_iterator
- end() const;
-
- inline reverse_iterator
- rbegin()
- {
- return (reverse_iterator(m_p_head->m_p_right));
- }
-
- inline const_reverse_iterator
- rbegin() const;
-
- inline reverse_iterator
- find_rend();
-
- inline const_reverse_iterator
- find_rend() const;
-
- inline reverse_iterator
- rend();
-
- inline const_reverse_iterator
- rend() const;
-
- bool
- join_prep(PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- join_finish(PB_ASSOC_CLASS_C_DEC& r_other);
-
- bool
- split_prep(const_key_reference r_key, PB_ASSOC_CLASS_C_DEC& r_other);
-
- void
- split_finish(PB_ASSOC_CLASS_C_DEC& r_other);
-
- size_type
- recursive_count(node_pointer p_nd) const;
-
- inline const_node_iterator
- node_begin() const;
-
- inline node_iterator
- node_begin();
-
- inline const_node_iterator
- node_end() const;
-
- inline node_iterator
- node_end();
-
- private:
-
- inline std::pair
- erase(node_pointer p_nd);
-
-#ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-
- void
- assert_valid(bool check_iterators, bool check_metadata) const;
-
- std::pair
- assert_node_consistent(const node_pointer p_nd) const
- {
- if (p_nd == NULL)
- return (std::make_pair((const_pointer)NULL,(const_pointer)NULL));
-
- assert_node_consistent_with_left(p_nd);
- assert_node_consistent_with_right(p_nd);
-
- const std::pair
- l_range =
- assert_node_consistent(p_nd->m_p_left);
-
- if (l_range.second != NULL)
- PB_ASSOC_DBG_ASSERT(Cmp_Fn::operator()(
- PB_ASSOC_V2F(*l_range.second),
- PB_ASSOC_V2F(p_nd->m_value)));
-
- const std::pair
- r_range =
- assert_node_consistent(p_nd->m_p_right);
-
- if (r_range.first != NULL)
- PB_ASSOC_DBG_ASSERT(Cmp_Fn::operator()(
- PB_ASSOC_V2F(p_nd->m_value),
- PB_ASSOC_V2F(*r_range.first)));
-
- return (std::make_pair((l_range.first != NULL)? l_range.first :& p_nd->m_value,(r_range.second != NULL)? r_range.second :& p_nd->m_value));
- }
-
- void
- assert_consistent_with_debug_base() const;
-
- void
- assert_node_consistent_with_left(const node_pointer p_nd) const;
-
- void
- assert_node_consistent_with_right(const node_pointer p_nd) const;
-
- void
- assert_consistent_with_debug_base(const node_pointer p_nd) const;
-
- void
- assert_min() const;
-
- void
- assert_min_imp(const node_pointer p_nd) const;
-
- void
- assert_max() const;
-
- void
- assert_max_imp(const node_pointer p_nd) const;
-
- void
- assert_iterators() const;
-
- void
- assert_size() const;
-
-#endif // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-
- void
- initialize();
-
- node_pointer
- recursive_copy_node(const node_pointer p_nd);
-
- inline node_pointer
- get_new_node_for_leaf_insert(const_reference r_val, pb_assoc::detail::int_to_type);
-
- inline node_pointer
- get_new_node_for_leaf_insert(const_reference r_val, pb_assoc::detail::int_to_type);
-
- inline iterator
- insert_imp_empty(const_reference r_value);
-
- inline iterator
- insert_leaf_new(const_reference r_value, node_pointer p_nd, bool left_nd);
-
- static void
- clear_imp(node_pointer p_nd);
-
- protected:
- node_pointer m_p_head;
-
- iterator m_end_it;
-
- reverse_iterator m_rend_it;
-
- size_type m_size;
-
- static node_allocator s_node_allocator;
- };
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef PB_ASSOC_CLASS_C_DEC
-
-#undef PB_ASSOC_CLASS_T_DEC
-
-#undef PB_ASSOC_CLASS_NAME
-
-#undef PB_ASSOC_TYPES_TRAITS_C_DEC
-
-#undef PB_ASSOC_MAP_DEBUG_BASE_C_DEC
-
-#undef PB_ASSOC_V2F
-#undef PB_ASSOC_EP2VP
-#undef PB_ASSOC_V2S
-
-#undef PB_ASSOC_DBG_ASSERT
-#undef PB_ASSOC_DBG_VERIFY
-#undef PB_ASSOC_DBG_ONLY
-
- } // namespace detail
-
-} // namespace pb_assoc
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp
deleted file mode 100644
index 37048874f5a..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/cond_dtor_entry_dealtor.hpp
+++ /dev/null
@@ -1,74 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file cond_dtor_entry_dealtor.hpp
- * Contains a binary tree container conditional deallocator
- */
-
-class bin_search_tree_cond_dtor_entry_dealtor_
-{
-public:
- inline
- bin_search_tree_cond_dtor_entry_dealtor_(node_pointer p_nd) : m_p_nd(p_nd),
- m_no_action_dtor(false)
- { }
-
- inline void
- set_no_action_dtor()
- {
- m_no_action_dtor = true;
- }
-
- inline
- ~bin_search_tree_cond_dtor_entry_dealtor_()
- {
- if (m_no_action_dtor)
- return;
-
- typename Allocator::template rebind::other().
- deallocate(m_p_nd, 1);
- }
-
-protected:
- node_pointer m_p_nd;
-
- bool m_no_action_dtor;
-};
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp
deleted file mode 100644
index 022404fb66d..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/cond_key_dtor_entry_dealtor.hpp
+++ /dev/null
@@ -1,85 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file cond_key_dtor_entry_dealtor.hpp
- * Contains a binary tree container conditional deallocator
- */
-
-class bin_seach_tree_cond_key_dtor_entry_dealtor_
-{
-public:
- inline
- bin_seach_tree_cond_key_dtor_entry_dealtor_(node_pointer p_nd) : m_p_nd(p_nd),
- m_no_action_dtor(false),
- m_key_destruct(false)
- { }
-
- inline void
- set_no_action_dtor()
- {
- m_no_action_dtor = true;
- }
-
- inline void
- set_key_destruct()
- {
- m_key_destruct = true;
- }
-
- inline
- ~bin_seach_tree_cond_key_dtor_entry_dealtor_()
- {
- if (m_no_action_dtor)
- return;
-
- if (m_key_destruct)
- m_p_nd->m_value.first.~Key();
-
- my_bin_tree_base::s_alloc.deallocate(m_p_nd, 1);
- }
-
-protected:
- node_pointer m_p_nd;
-
- bool m_no_action_dtor;
-
- bool m_key_destruct;
-};
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp
deleted file mode 100644
index 4020e62f4f7..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp
+++ /dev/null
@@ -1,258 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file constructors_destructor_fn_imps.hpp
- * Contains an implementation class for bin_search_tree_.
- */
-
-PB_ASSOC_CLASS_T_DEC
-typename PB_ASSOC_CLASS_C_DEC::node_allocator
-PB_ASSOC_CLASS_C_DEC::s_node_allocator;
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-PB_ASSOC_CLASS_NAME() :
- m_p_head(s_node_allocator.allocate(1)),
- m_end_it(m_p_head),
- m_rend_it(m_p_head),
- m_size(0)
-{
- initialize();
-
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- }
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-PB_ASSOC_CLASS_NAME(const Cmp_Fn& r_cmp_fn) :
- Cmp_Fn(r_cmp_fn),
- m_p_head(s_node_allocator.allocate(1)),
- m_end_it(m_p_head),
- m_rend_it(m_p_head),
- m_size(0)
-{
- initialize();
-
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- }
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-PB_ASSOC_CLASS_NAME(const Cmp_Fn& r_cmp_fn, const Node_Updator& r_node_updator) :
- Cmp_Fn(r_cmp_fn),
- Node_Updator(r_node_updator),
- m_p_head(s_node_allocator.allocate(1)),
- m_end_it(m_p_head),
- m_rend_it(m_p_head),
- m_size(0)
-{
- initialize();
-
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- }
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-PB_ASSOC_CLASS_NAME(const PB_ASSOC_CLASS_C_DEC& r_other) :
-#ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
- my_map_debug_base(r_other),
-#endif // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
- Cmp_Fn(r_other),
- Node_Updator(r_other),
- m_p_head(s_node_allocator.allocate(1)),
- m_end_it(m_p_head),
- m_rend_it(m_p_head),
- m_size(0)
-{
- initialize();
-
- m_size = r_other.m_size;
-
- PB_ASSOC_DBG_ONLY(r_other.assert_valid(true, true);)
-
- try
- {
- m_p_head->m_p_parent =
- recursive_copy_node(r_other.m_p_head->m_p_parent);
-
- if (m_p_head->m_p_parent != NULL)
- m_p_head->m_p_parent->m_p_parent = m_p_head;
-
- m_size = r_other.m_size;
-
- initialize_min_max();
- }
- catch(...)
- {
- PB_ASSOC_DBG_ONLY(my_map_debug_base::clear();)
-
- s_node_allocator.deallocate(m_p_head, 1);
-
- throw;
- }
-
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- }
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-swap(PB_ASSOC_CLASS_C_DEC& r_other)
-{
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- PB_ASSOC_DBG_ONLY(r_other.assert_valid(true, true);)
-
- PB_ASSOC_DBG_ONLY(my_map_debug_base::swap(r_other);)
-
- std::swap(m_p_head, r_other.m_p_head);
-
- std::swap(m_size, r_other.m_size);
-
- std::swap(m_end_it, r_other.m_end_it);
-
- std::swap(m_rend_it, r_other.m_rend_it);
-
- std::swap((Cmp_Fn& )(*this), (Cmp_Fn& )r_other);
-
- Node_Updator::swap(r_other);
-
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- PB_ASSOC_DBG_ONLY(r_other.assert_valid(true, true);)
- }
-
-PB_ASSOC_CLASS_T_DEC
-PB_ASSOC_CLASS_C_DEC::
-~PB_ASSOC_CLASS_NAME()
-{
- clear();
-
- s_node_allocator.deallocate(m_p_head, 1);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-initialize()
-{
- m_p_head->m_p_parent = NULL;
- m_p_head->m_p_left = m_p_head;
- m_p_head->m_p_right = m_p_head;
-
- m_size = 0;
-}
-
-PB_ASSOC_CLASS_T_DEC
-typename PB_ASSOC_CLASS_C_DEC::node_pointer
-PB_ASSOC_CLASS_C_DEC::
-recursive_copy_node(const node_pointer p_nd)
-{
- if (p_nd == NULL)
- return (NULL);
-
- node_pointer p_ret = s_node_allocator.allocate(1);
-
- try
- {
- new (p_ret) node(*p_nd);
- }
- catch(...)
- {
- s_node_allocator.deallocate(p_ret, 1);
-
- throw;
- }
-
- p_ret->m_p_left = p_ret->m_p_right = NULL;
-
- try
- {
- p_ret->m_p_left = recursive_copy_node(p_nd->m_p_left);
-
- p_ret->m_p_right = recursive_copy_node(p_nd->m_p_right);
- }
- catch(...)
- {
- clear_imp(p_ret);
-
- throw;
- }
-
- if (p_ret->m_p_left != NULL)
- p_ret->m_p_left->m_p_parent = p_ret;
-
- if (p_ret->m_p_right != NULL)
- p_ret->m_p_right->m_p_parent = p_ret;
-
- PB_ASSOC_DBG_ONLY(assert_node_consistent(p_ret);)
-
- return (p_ret);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-initialize_min_max()
-{
- if (m_p_head->m_p_parent == NULL)
- {
- m_p_head->m_p_left = m_p_head->m_p_right = m_p_head;
-
- return;
- }
-
- {
- node_pointer p_min = m_p_head->m_p_parent;
-
- while (p_min->m_p_left != NULL)
- p_min = p_min->m_p_left;
-
- m_p_head->m_p_left = p_min;
- }
-
- {
- node_pointer p_max = m_p_head->m_p_parent;
-
- while (p_max->m_p_right != NULL)
- p_max = p_max->m_p_right;
-
- m_p_head->m_p_right = p_max;
- }
-}
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/debug_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/debug_fn_imps.hpp
deleted file mode 100644
index f3b12d06d6f..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/debug_fn_imps.hpp
+++ /dev/null
@@ -1,278 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file debug_fn_imps.hpp
- * Contains an implementation class for bin_search_tree_.
- */
-
-#ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_valid(bool check_iterators, bool check_metadata) const
-{
- PB_ASSOC_DBG_ASSERT(m_p_head != NULL);
-
- if (m_p_head->m_p_parent == NULL)
- {
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_left == m_p_head);
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_right == m_p_head);
-
- if (check_metadata)
- PB_ASSOC_DBG_ASSERT(m_size == 0);
- }
- else
- {
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_parent->m_p_parent == m_p_head);
-
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_left != m_p_head);
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_right != m_p_head);
-
- if (check_metadata)
- PB_ASSOC_DBG_ASSERT(m_size > 0);
- }
-
- if (check_metadata)
- assert_size();
-
- if (m_p_head->m_p_parent != NULL)
- assert_node_consistent(m_p_head->m_p_parent);
-
- assert_min();
- assert_max();
-
- if (check_metadata)
- assert_consistent_with_debug_base();
-
- if (check_iterators&& check_metadata)
- assert_iterators();
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_node_consistent_with_left(const node_pointer p_nd) const
-{
- if (p_nd->m_p_left == NULL)
- return;
-
- PB_ASSOC_DBG_ASSERT(p_nd->m_p_left->m_p_parent == p_nd);
-
- PB_ASSOC_DBG_ASSERT(!Cmp_Fn::operator()(
- PB_ASSOC_V2F(p_nd->m_value),
- PB_ASSOC_V2F(p_nd->m_p_left->m_value)));
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_node_consistent_with_right(const node_pointer p_nd) const
-{
- if (p_nd->m_p_right == NULL)
- return;
-
- PB_ASSOC_DBG_ASSERT(p_nd->m_p_right->m_p_parent == p_nd);
-
- PB_ASSOC_DBG_ASSERT(!Cmp_Fn::operator()(
- PB_ASSOC_V2F(p_nd->m_p_right->m_value),
- PB_ASSOC_V2F(p_nd->m_value)));
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_min() const
-{
- assert_min_imp(m_p_head->m_p_parent);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_min_imp(const node_pointer p_nd) const
-{
- if (p_nd == NULL)
- {
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_left == m_p_head);
-
- return;
- }
-
- if (p_nd->m_p_left == NULL)
- {
- PB_ASSOC_DBG_ASSERT(p_nd == m_p_head->m_p_left);
-
- return;
- }
-
- assert_min_imp(p_nd->m_p_left);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_max() const
-{
- assert_max_imp(m_p_head->m_p_parent);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_max_imp(const node_pointer p_nd) const
-{
- if (p_nd == NULL)
- {
- PB_ASSOC_DBG_ASSERT(m_p_head->m_p_right == m_p_head);
-
- return;
- }
-
- if (p_nd->m_p_right == NULL)
- {
- PB_ASSOC_DBG_ASSERT(p_nd == m_p_head->m_p_right);
-
- return;
- }
-
- assert_max_imp(p_nd->m_p_right);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_iterators() const
-{
- PB_ASSOC_DBG_ASSERT(m_end_it.m_p_nd == m_p_head);
- PB_ASSOC_DBG_ASSERT(m_rend_it.m_p_nd == m_p_head);
-
- size_type iterated_num = 0;
-
- const_iterator prev_it = end();
-
- for (const_iterator it = begin(); it != end(); ++it)
- {
- ++iterated_num;
-
- PB_ASSOC_DBG_ASSERT(lower_bound(
- PB_ASSOC_V2F(*it)).m_p_nd == it.m_p_nd);
-
- const_iterator upper_bound_it = upper_bound(
- PB_ASSOC_V2F(*it));
-
- --upper_bound_it;
-
- PB_ASSOC_DBG_ASSERT(upper_bound_it.m_p_nd == it.m_p_nd);
-
- if (prev_it != end())
- PB_ASSOC_DBG_ASSERT(Cmp_Fn::operator()(
- PB_ASSOC_V2F(*prev_it),
- PB_ASSOC_V2F(*it)));
-
- prev_it = it;
- }
-
- PB_ASSOC_DBG_ASSERT(iterated_num == m_size);
-
- size_type reverse_iterated_num = 0;
-
- const_reverse_iterator reverse_prev_it = rend();
-
- for (const_reverse_iterator reverse_it = rbegin(); reverse_it != rend();
- ++reverse_it)
- {
- ++reverse_iterated_num;
-
- PB_ASSOC_DBG_ASSERT(lower_bound(
- PB_ASSOC_V2F(*reverse_it)).m_p_nd == reverse_it.m_p_nd);
-
- const_iterator upper_bound_it = upper_bound(
- PB_ASSOC_V2F(*reverse_it));
-
- --upper_bound_it;
-
- PB_ASSOC_DBG_ASSERT(upper_bound_it.m_p_nd == reverse_it.m_p_nd);
-
- if (reverse_prev_it != rend())
- PB_ASSOC_DBG_ASSERT(!Cmp_Fn::operator()(
- PB_ASSOC_V2F(*reverse_prev_it),
- PB_ASSOC_V2F(*reverse_it)));
-
- reverse_prev_it = reverse_it;
- }
-
- PB_ASSOC_DBG_ASSERT(reverse_iterated_num == m_size);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_consistent_with_debug_base() const
-{
- my_map_debug_base::check_size(m_size);
-
- assert_consistent_with_debug_base(m_p_head->m_p_parent);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_consistent_with_debug_base(const node_pointer p_nd) const
-{
- if (p_nd == NULL)
- return;
-
- my_map_debug_base::check_key_exists(
- PB_ASSOC_V2F(p_nd->m_value));
-
- assert_consistent_with_debug_base(p_nd->m_p_left);
- assert_consistent_with_debug_base(p_nd->m_p_right);
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-assert_size() const
-{
- PB_ASSOC_DBG_ASSERT(recursive_count(m_p_head->m_p_parent) == m_size);
-}
-
-#endif // #ifdef PB_ASSOC_BIN_SEARCH_TREE_DEBUG_
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/erase_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/erase_fn_imps.hpp
deleted file mode 100644
index cceea5134ee..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/erase_fn_imps.hpp
+++ /dev/null
@@ -1,124 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file erase_fn_imps.hpp
- * Contains an implementation class for bin_search_tree_.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline void
-PB_ASSOC_CLASS_C_DEC::
-actual_erase_node(node_pointer p_z)
-{
- PB_ASSOC_DBG_ASSERT(m_size > 0);
- --m_size;
-
- PB_ASSOC_DBG_ONLY(erase_existing(PB_ASSOC_V2F(p_z->m_value)));
-
- p_z->~node();
-
- s_node_allocator.deallocate(p_z, 1);
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline void
-PB_ASSOC_CLASS_C_DEC::
-update_min_max_for_erased_node(node_pointer p_z)
-{
- if (m_size == 1)
- {
- m_p_head->m_p_left = m_p_head->m_p_right = m_p_head;
-
- return;
- }
-
- if (m_p_head->m_p_left == p_z)
- {
- iterator it(p_z);
-
- ++it;
-
- m_p_head->m_p_left = it.m_p_nd;
- }
- else if (m_p_head->m_p_right == p_z)
- {
- iterator it(p_z);
-
- --it;
-
- m_p_head->m_p_right = it.m_p_nd;
- }
-}
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-clear()
-{
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
-
- clear_imp(m_p_head->m_p_parent);
-
- m_size = 0;
-
- initialize();
-
- PB_ASSOC_DBG_ONLY(my_map_debug_base::clear();)
-
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
- }
-
-PB_ASSOC_CLASS_T_DEC
-void
-PB_ASSOC_CLASS_C_DEC::
-clear_imp(node_pointer p_nd)
-{
- if (p_nd == NULL)
- return;
-
- clear_imp(p_nd->m_p_left);
-
- clear_imp(p_nd->m_p_right);
-
- p_nd->~Node();
-
- s_node_allocator.deallocate(p_nd, 1);
-}
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/find_fn_imps.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/find_fn_imps.hpp
deleted file mode 100644
index 436cd25f861..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/find_fn_imps.hpp
+++ /dev/null
@@ -1,184 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file find_fn_imps.hpp
- * Contains an implementation class for bin_search_tree_.
- */
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_find_iterator
-PB_ASSOC_CLASS_C_DEC::
-lower_bound(const_key_reference r_key) const
-{
- node_pointer p_pot = m_p_head;
- node_pointer p_nd = m_p_head->m_p_parent;
-
- while (p_nd != NULL)
- if (!Cmp_Fn::operator()(PB_ASSOC_V2F(p_nd->m_value), r_key))
- {
- p_pot = p_nd;
-
- p_nd = p_nd->m_p_left;
- }
- else
- p_nd = p_nd->m_p_right;
-
- return (iterator(p_pot));
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::find_iterator
-PB_ASSOC_CLASS_C_DEC::
-lower_bound(const_key_reference r_key)
-{
- node_pointer p_pot = m_p_head;
- node_pointer p_nd = m_p_head->m_p_parent;
-
- while (p_nd != NULL)
- if (!Cmp_Fn::operator()(
- PB_ASSOC_V2F(p_nd->m_value),
- r_key))
- {
- p_pot = p_nd;
-
- p_nd = p_nd->m_p_left;
- }
- else
- p_nd = p_nd->m_p_right;
-
- return (iterator(p_pot));
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_find_iterator
-PB_ASSOC_CLASS_C_DEC::
-upper_bound(const_key_reference r_key) const
-{
- node_pointer p_pot = m_p_head;
- node_pointer p_nd = m_p_head->m_p_parent;
-
- while (p_nd != NULL)
- if (Cmp_Fn::operator()(r_key,
- PB_ASSOC_V2F(p_nd->m_value)))
- {
- p_pot = p_nd,
-
- p_nd = p_nd->m_p_left;
- }
- else
- p_nd = p_nd->m_p_right;
-
- return (const_iterator(p_pot));
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::find_iterator
-PB_ASSOC_CLASS_C_DEC::
-upper_bound(const_key_reference r_key)
-{
- node_pointer p_pot = m_p_head;
- node_pointer p_nd = m_p_head->m_p_parent;
-
- while (p_nd != NULL)
- if (Cmp_Fn::operator()(r_key,
- PB_ASSOC_V2F(p_nd->m_value)))
- {
- p_pot = p_nd,
-
- p_nd = p_nd->m_p_left;
- }
- else
- p_nd = p_nd->m_p_right;
-
- return (find_iterator(p_pot));
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::find_iterator
-PB_ASSOC_CLASS_C_DEC::
-find(const_key_reference r_key)
-{
- PB_ASSOC_DBG_ONLY(assert_valid(true, false);)
-
- node_pointer p_pot = m_p_head;
- node_pointer p_nd = m_p_head->m_p_parent;
-
- while (p_nd != NULL)
- if (!Cmp_Fn::operator()(PB_ASSOC_V2F(p_nd->m_value), r_key))
- {
- p_pot = p_nd;
-
- p_nd = p_nd->m_p_left;
- }
- else
- p_nd = p_nd->m_p_right;
-
- return find_iterator((p_pot != m_p_head&& Cmp_Fn::operator()(
- r_key,
- PB_ASSOC_V2F(p_pot->m_value)))?
- m_p_head : p_pot);
-}
-
-PB_ASSOC_CLASS_T_DEC
-inline typename PB_ASSOC_CLASS_C_DEC::const_find_iterator
-PB_ASSOC_CLASS_C_DEC::
-find(const_key_reference r_key) const
-{
- PB_ASSOC_DBG_ONLY(assert_valid(true, true);)
-
- node_pointer p_pot = m_p_head;
- node_pointer p_nd = m_p_head->m_p_parent;
-
- while (p_nd != NULL)
- if (!Cmp_Fn::operator()(PB_ASSOC_V2F(p_nd->m_value), r_key))
- {
- p_pot = p_nd;
-
- p_nd = p_nd->m_p_left;
- }
- else
- p_nd = p_nd->m_p_right;
-
- return const_find_iterator((p_pot != m_p_head&& Cmp_Fn::operator()(
- r_key,
- PB_ASSOC_V2F(p_pot->m_value)))?
- m_p_head : p_pot);
-}
-
diff --git a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/find_iterators.hpp b/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/find_iterators.hpp
deleted file mode 100644
index d6ddadc7a55..00000000000
--- a/libstdc++-v3/include/ext/pb_assoc/detail/bin_search_tree_/find_iterators.hpp
+++ /dev/null
@@ -1,391 +0,0 @@
-// -*- C++ -*-
-
-// Copyright (C) 2005 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 2, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING. If not, write to the Free
-// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
-// USA.
-
-// As a special exception, you may use this file as part of a free software
-// library without restriction. Specifically, if other files instantiate
-// templates or use macros or inline functions from this file, or you compile
-// this file and link it with other files to produce an executable, this
-// file does not by itself cause the resulting executable to be covered by
-// the GNU General Public License. This exception does not however
-// invalidate any other reasons why the executable file might be covered by
-// the GNU General Public License.
-
-// Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
-
-// Permission to use, copy, modify, sell, and distribute this software
-// is hereby granted without fee, provided that the above copyright
-// notice appears in all copies, and that both that copyright notice and
-// this permission notice appear in supporting documentation. None of
-// the above authors, nor IBM Haifa Research Laboratories, make any
-// representation about the suitability of this software for any
-// purpose. It is provided "as is" without express or implied warranty.
-
-/**
- * @file find_iterators.hpp
- * Contains an implementation class for bin_search_tree_.
- */
-
-#define PB_ASSOC_CONST_IT_C_DEC \
- const_it_< \
- Is_Forward_Iterator>
-
-#define PB_ASSOC_CONST_ODIR_IT_C_DEC \
- const_it_< \
- !Is_Forward_Iterator>
-
-#define PB_ASSOC_IT_C_DEC \
- it_< \
- Is_Forward_Iterator>
-
-#define PB_ASSOC_ODIR_IT_C_DEC \
- it_< \
- !Is_Forward_Iterator>
-
-template
-class const_it_
-{
-
-public:
-
- typedef std::bidirectional_iterator_tag iterator_category;
-
- typedef typename Allocator::difference_type difference_type;
-
- typedef mapped_value_type value_type;
-
- typedef mapped_pointer pointer;
-
- typedef const_mapped_pointer const_pointer;
-
- typedef mapped_reference reference;
-
- typedef const_mapped_reference const_reference;
-
-public:
-
- inline
- const_it_(const node_pointer p_nd = NULL) : m_p_nd(const_cast(p_nd))
- { }
-
- inline
- const_it_(const PB_ASSOC_CONST_ODIR_IT_C_DEC&
- r_other)
-
- : m_p_nd(r_other.m_p_nd)
- { }
-
- inline
- PB_ASSOC_CONST_IT_C_DEC&
- operator=(const PB_ASSOC_CONST_IT_C_DEC&
- r_other)
- {
- m_p_nd = r_other.m_p_nd;
-
- return (*this);
- }
-
- inline
- PB_ASSOC_CONST_IT_C_DEC&
- operator=(const PB_ASSOC_CONST_ODIR_IT_C_DEC&
- r_other)
- {
- m_p_nd = r_other.m_p_nd;
-
- return (*this);
- }
-
- inline const_pointer
- operator->() const
- {
- PB_ASSOC_DBG_ASSERT(m_p_nd != NULL);
-
- return (&m_p_nd->m_value);
- }
-
- inline const_reference
- operator*() const
- {
- PB_ASSOC_DBG_ASSERT(m_p_nd != NULL);
-
- return (m_p_nd->m_value);
- }
-
- inline bool
- operator==(const PB_ASSOC_CONST_IT_C_DEC
- &r_other) const
- {
- return (m_p_nd == r_other.m_p_nd);
- }
-
- inline bool
- operator==(const PB_ASSOC_CONST_ODIR_IT_C_DEC
- &r_other) const
- {
- return (m_p_nd == r_other.m_p_nd);
- }
-
- inline bool
- operator!=(const PB_ASSOC_CONST_IT_C_DEC&
- r_other) const
- {
- return (m_p_nd != r_other.m_p_nd);
- }
-
- inline bool
- operator!=(const PB_ASSOC_CONST_ODIR_IT_C_DEC&
- r_other) const
- {
- return (m_p_nd != r_other.m_p_nd);
- }
-
- inline PB_ASSOC_CONST_IT_C_DEC&
- operator++()
- {
- PB_ASSOC_DBG_ASSERT(m_p_nd != NULL);
-
- inc(int_to_type());
-
- return (*this);
- }
-
- inline PB_ASSOC_CONST_IT_C_DEC
- operator++(int)
- {
- PB_ASSOC_CONST_IT_C_DEC
- ret_it(m_p_nd);
-
- operator++();
-
- return (ret_it);
- }
-
- inline PB_ASSOC_CONST_IT_C_DEC&
- operator--()
- {
- dec(int_to_type());
-
- return (*this);
- }
-
- inline PB_ASSOC_CONST_IT_C_DEC
- operator--(int)
- {
- PB_ASSOC_CONST_IT_C_DEC
- ret_it(m_p_nd);
-
- operator--();
-
- return (ret_it);
- }
-
-protected:
- inline void
- inc(int_to_type)
- {
- dec(int_to_type());
- }
-
- void
- inc(int_to_type)
- {
- if (m_p_nd->m_p_right != NULL)
- {
- m_p_nd = m_p_nd->m_p_right;
-
- while (m_p_nd->m_p_left != NULL)
- m_p_nd = m_p_nd->m_p_left;
-
- return;
- }
-
- node_pointer p_y = m_p_nd->m_p_parent;
-
- while (m_p_nd == p_y->m_p_right)
- {
- m_p_nd = p_y;
-
- p_y = p_y->m_p_parent;
- }
-
- if (m_p_nd->m_p_right != p_y)
- m_p_nd = p_y;
- }
-
- inline void
- dec(int_to_type