- The unset() method never auto-vivifies, whereas the set() method
always auto-vivifies. In the case where set() is called with a zero
for its argument - eg, set(index, 0) - this should behave
identically to an unset() and not auto-vivify out-of-range entries.
- This follows the same idea as cbegin/cend and is helpful when using
C++11 auto to ensure we have unambiguous const-safe access.
Previously:
====
typename someLongClass::const_iterator iter = someTable.find(key);
... later on:
*iter = value; // Oops, but caught by compiler.
We can save some typing with auto, but it is uncertain what we get:
====
auto iter = someTable.find(key);
// iterator or const_iterator?
// depends on someTable having const or non-const access.
... later on:
*iter = value; // Oops, but not caught by compiler.
Using cfind instead, auto will deduce const_iterator as the type:
====
auto iter = someTable.cfind(key); // definitely const_iterator
... later on:
*iter = value; // Oops, but caught by compiler.
Some versions of lsof print the mount point (if remote) after the
script path:
/hosts/mymachine/OpenFOAM/OpenFOAM-plus.develop/etc/cshrc (mymachine:/home)
This now gets filtered out.
- provides a summary hash of classes used and their associated object names.
The HashTable representation allows us to leverage various HashTable
methods. This hashed summary view can be useful when querying
particular aspects, but is most useful when reducing the objects in
consideration to a particular subset. For example,
const wordHashSet interestingTypes
{
volScalarField::typeName,
volVectorField::typeName
};
IOobjectList objects(runTime, runTime.timeName());
HashTable<wordHashSet> classes = objects.classes();
classes.retain(interestingTypes);
// Or do just the opposite:
classes.erase(unsupportedTypes);
Can also use the underlying HashTable filter methods
STYLE: use templated internals to avoid findString() when matching subsets
- Generalized means over filtering table entries based on their keys,
values, or both. Either filter (retain), or optionally prune elements
that satisfy the specified predicate.
filterKeys and filterValues:
- Take a unary predicate with the signature
bool operator()(const Key& k);
- filterEntries:
Takes a binary predicate with the signature
bool operator()(const Key& k, const T& v);
==
The predicates can be normal class methods, or provide on-the-fly
using a C++ lambda. For example,
wordRes goodFields = ...;
allFieldNames.filterKeys
(
[&goodFields](const word& k){ return goodFields.match(k); }
);
Note that all classes that can match a string (eg, regExp, keyType,
wordRe, wordRes) or that are derived from a Foam::string (eg, fileName,
word) are provided with a corresponding
bool operator()(const std::string&)
that either performs a regular expression or a literal match.
This allows such objects to be used directly as a unary predicate
when filtering any string hash keys.
Note that HashSet and hashedWordList both have the proper
operator() methods that also allow them to be used as a unary
predicate.
- Similar predicate selection with the following:
* tocKeys, tocValues, tocEntries
* countKeys, countValues, countEntries
except that instead of pruning, there is a simple logic inversion.
- predicates::always and predicates::never returning true and false,
respectively. These simple classes make it easier when writing
templated code.
As well as unary and binary predicate forms, they also contain a
match(std::string) method for compatibility with regex-based classes.
STYLE: write bool and direction as primitive 'int' not as 'label'.
- ensure that the string-related classes have consistently similar
matching methods. Use operator()(const std::string) as an entry
point for the match() method, which makes it easier to use for
filters and predicates. In some cases this will also permit using
a HashSet as a match predicate.
regExp
====
- the set method now returns a bool to signal that the requested
pattern was compiled.
wordRe
====
- have separate constructors with the compilation option (was previously
a default parameter). This leaves the single parameter constructor
explicit, but the two parameter version is now non-explicit, which
makes it easier to use when building lists.
- renamed compile-option from REGEX (to REGEXP) for consistency with
with the <regex.h>, <regex> header names etc.
wordRes
====
- renamed from wordReListMatcher -> wordRes. For reduced typing and
since it behaves as an entity only slightly related to its underlying
list nature.
- Provide old name as typedef and include for code transition.
- pass through some list methods into wordRes
hashedWordList
====
- hashedWordList[const word& name] now returns a -1 if the name is is
not found in the list of indices. That has been a pending change
ever since hashedWordList was generalized out of speciesTable
(Oct-2010).
- add operator()(const word& name) for easy use as a predicate
STYLE: adjust parameter names in stringListOps
- reflect if the parameter is being used as a primary matcher, or the
matcher will be derived from the parameter.
For example,
(const char* re), which first creates a regExp
versus (const regExp& matcher) which is used directly.
- can run doxygen with an alternative Doxyfile, which is useful
when verifying generated content for particular classes.
Eg,
PATH/doc/Allwmake -dir $PWD
