- construct Map/HashTable from key/value lists.
- invertToMap() : like invert() but returns a Map<label>,
which is useful for sparse numbering
- inplaceRenumber() : taking a Map<label> for the mapper
ENH: construct/reset CStringList for list of C-strings
- name and functionality similar to std::unordered_map (C++17).
Formalizes what had been previously been implemented in IOobjectList
but now manages without pointer deletion/creation.
- forwarding like the emplace() method, but overwriting existing
entries as required
- propagate similar changes to HashPtrTable
For example, with HashPtrTable<labelList> table(...) :
With 'insert' semantics
table.emplace("list1", 1000);
vs
if (!table.found("list1"))
{
table.set("list1", new labelList(1000));
}
or
table.insert("list1", autoPtr<labelList>::New(1000));
Note that the last example invokes an unnecessary allocation/deletion
if the insertion is unsuccessful.
With 'set' semantics:
table.emplace_set("list1", 15);
vs
table.set("list1", new labelList(15));
- this largely reverts 3f0f218d88 and 4ee65d12c4.
Consistent addressing with support for wrapped pointer types (eg,
autoPtr, std::unique_ptr) has proven to be less robust than desired.
Thus rescind HashTable iterator '->' dereferencing (from APR-2019).
- unfriend HashSet, HashTable IO operators
- global min(), max(), minMax() functions taking a labelHashSet and an
optional limit. For example,
labelHashSet set = ...;
Info<< "min is " << min(set) << nl;
Info<< "max (non-negative) " << max(set, 0) << nl;
- make HashTable iterator '->' dereferencing more consistent by also
supporting non-pointer types as well.
- read HashTable values in-situ to avoid copying
- support move insert/set and emplace insertion.
These adjustments can be used for improved memory efficiency, and
allow hash tables of non-copyable objects (eg, std::unique_ptr).
- extend special HashTable output treatment to include pointer-like
objects such as autoPtr and unique_ptr.
ENH: HashTable::at() method with checking. Fatal if entry does not exist.
- The capitalization is consistent with most other template classes, but
more importantly frees up xfer() for use as method name without needing
special treatment to avoid ambiguities.
It seems reasonable to have different names for transfer(...) and xfer()
methods, since the transfer is occuring in different directions.
The xfer() method can thus replace the recently introduced zero-parameter
transfer() methods.
Other name candidates (eg, yield, release, etc.) were deemed too abstract.
StaticHashTable:
- erase(iterator&) now actually alters the iterator and iterator++() handles
it properly
- clear() also sets count to zero
- operator=(const StaticHashTable&) doesn't crash after a previous transfer
- operator(), operator==() and operator!=() added
HashTable:
- operator=(const HashTable&) gets tableSize if required, eg, after a
previous transfer)
HashSet / Map
- add xfer<...> constructor for underlying HashTable
