- the NamedEnum wrapper is somewhate too rigid.
* All enumerated values are contiguous, starting as zero.
* The implicit one-to-one mapping precludes using it for aliases.
* For example, perhaps we want to support alternative lookup names for an
enumeration, or manage an enumeration lookup for a sub-range.
- Remove the unused enums() method since it delivers wholly unreliable
results. It is not guaranteed to cover the full enumeration range,
but only the listed names.
- Remove the unused strings() method.
Duplicated functionality of the words(), but was never used.
- Change access of words() method from static to object.
Better code isolation. Permits the constructor to take over
as the single point of failure for bad input.
- Add values() method
- do not expose internal (HashTable) lookup since it makes it more
difficult to enforce constness and the implementation detail should
not be exposed. However leave toc() and sortedToc() for the interface.
STYLE: relocated NamedEnum under primitives (was containers)
- internal typedef as 'value_type' for some consistency with STL conventions
- 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).
