- previously had a mismash of const/non-const attributes on iterators
that were confused with the attributes of the object being accessed.
- use the iterator keys() and object() methods consistently for all
internal access of the HashTable iterators. This makes the intention
clearer, the code easier to maintain, and protects against any
possible changes in the definition of the operators.
- 'operator*': The standard form expected by STL libraries.
However, for the std::map, this dereferences to a <key,value> pair,
whereas OpenFOAM dereferences simply to <value>.
- 'operator()': OpenFOAM treats this like the 'operator*'
- adjusted the values of end() and cend() to reinterpret from nullObject
instead of returning a static iteratorEnd() object.
This means that C++ templates can now correctly deduce and match
the return types from begin() and end() consistently.
So that range-based now works.
Eg,
HashTable<label> table1 = ...;
for (auto i : table1)
{
Info<< i << endl;
}
Since the 'operator*' returns hash table values, this prints all the
values in the table.
This uses a concept similar to what std::valarray and std::slice do.
A labelRange provides a convenient container for holding start/size
and lends itself to addressing 'sliced' views of lists.
For safety, the operations and constructors restricts the given input range
to a valid addressible region of the underlying list, while the labelRange
itself precludes negative sizes.
The SubList version is useful for patches or other things that have a
SubList as its parameter. Otherwise the UList [] operator will be the
more natural solution. The slices can be done with a labelRange, or
a {start,size} pair.
Examples,
labelList list1 = identity(20);
list1[labelRange(18,10)] = -1;
list1[{-20,25}] = -2;
list1[{1000,5}] = -3;
const labelList list2 = identity(20);
list2[{5,10}] = -3; // ERROR: cannot assign to const!
- optimize erasure using different HashTable based on its size.
Eg, hashtable.erase(other);
If 'other' is smaller than the hashtable, it is more efficient to
use the keys from other to remove from the hashtable.
Otherwise simply iterate over the hashtable and remove it if
that key was found in other.
- some functionality similar to what the standary library <iterator>
provides.
* stdFoam::begin() and stdFoam::end() do type deduction,
which means that many cases it is possible to manage these types
of changes.
For example, when managing a number of indices:
Map<labelHashSet> lookup;
1) Longhand:
for
(
Map<labelHashSet>::const_iterator iter = lookup.begin();
iter != lookup.end();
++iter
)
{ .... }
1b) The same, but wrapped via a macro:
forAllConstIter(Map<labelHashSet>, lookup, iter)
{ .... }
2) Using stdFoam begin/end templates directly
for
(
auto iter = stdFoam::begin(lookup);
iter != stdFoam::end(lookup);
++iter
)
{ .... }
2b) The same, but wrapped via a macro:
forAllConstIters(lookup, iter)
{ .... }
Note that in many cases it is possible to simply use a range-based for.
Eg,
labelList myList;
for (auto val : myList)
{ ... }
for (const auto& val : myList)
{ ... }
These however will not work with any of the OpenFOAM hash-tables,
since the standard C++ concept of an iterator would return a key,value
pair when deferencing the *iter.
The deduction methods also exhibits some slightly odd behaviour with
some PtrLists (needs some more investigation).
- make construct from UList explicit and provide corresponding
assignment operator.
- add construct,insert,set,assignment from FixedList.
This is convenient when dealing with things like edges or triFaces.
- explicitly mention the value-initialized status for the operator().
This means that the following code will properly use an initialized
zero.
HashTable<label> regionCount;
if (...)
regionCount("region1")++;
... and also this;
if (regionCount("something") > 0)
{
...
}
Note that the OpenFOAM HashTable uses operator[] to provide read and
write access to *existing* entries and will provoke a FatalError if
the entry does not exist.
The operator() provides write access to *existing* entries or will
create the new entry as required.
The STL hashes use operator[] for this purpose.
- more hash-like methods.
Eg, insert/erase via lists, clear(), empty(),...
- minVertex(), maxVertex() to return the smallest/largest label used
- improved documentation, more clarification about where/how negative
point labels are treated.
- cannot use comparison of list sizes. Okay for UList, but not here.
STYLE:
- don't need two iterators for the '<' comparison, can just access
internal storage directly
By specifying the optional outside surface emissivity radiative heat transfer to
the ambient conditions is enabled. The far-field is assumed to have an
emissivity of 1 but this could be made an optional input in the future if
needed.
Relaxation of the surface temperature is now provided via the optional
"relaxation" which aids stability of steady-state runs with strong radiative
coupling to the boundary.
- The existing ':' anchor works for rvalue substitutions
(Eg, ${:subdict.name}), but fails for lvalues, since it is
a punctuation token and parse stops there.
- support edge-ordering on construction, and additional methods:
- sort(), sorted(), unitVec(), collapse()
- null constructor initializes with -1, for consistency with face,
triFace and since it is generally much more useful that way.
- add some methods that allow edges to used somewhat more like hashes.
- count(), found(), insert(), erase()
Here is possible way to use that:
edge someEdge; // initializes with '-1' for both entries
if (someEdge.insert(pt1))
{
// added a new point label
}
... later
// unmark point on edge
someEdge.erase(pt2);
--
STYLE:
- use UList<point> instead of pointField for edge methods for flexibility.
The pointField include is retained, however, since many other routines
may be relying on it being included via edge.H
