Conflicts:
applications/utilities/mesh/manipulation/createBaffles/createBaffles.C
Can't use [0] to assign the first value of a DynamicList unless it has been
preceded by a setSize() - use append() instead.
- change system/controlDict to use functions {..} instead of functions (..);
* This is internally more efficient
- fixed formatting of system/controlDict functions entry
- pedantic change: use 'return 0' instead of 'return(0)' in the applications,
since return is a C/C++ keyword, not a function.
- this (now deprecated) idiom:
for (runTime++; !runTime.end(); runTime++) { ... }
has a few problems:
* stop-on-next-write will be off-by-one (ie, doesn't work)
* function objects are not executed on exit with runTime.end()
Fixing these problems is not really possible.
- this idiom
while (runTime.run())
{
runTime++;
...
}
works without the above problems.
- removed the previously added fileName type(), isDir(), isFile() methods.
- added optional bool parameter to isFile() function to explicitly
enable/disable the check for gzip files.
- fixed minor bugginess where the default usage of isFile() would result in
false positive matches.
- be slightly more stringent and use isDir() and isFile() instead of
exists() function when we actually know the expected type.
- can use 'XX.empty()' instead of 'XX.size() == 0', 'XX.size() < 1' or
'XX.size() <= 0' or for simpler coding.
It also has the same number of characters as '!XX.size()' and /might/ be
more readable
- many size checking had 'XX.size() > 0', 'XX.size() != 0', or 'XX.size() >= 1'
when a simple 'XX.size()' suffices
- string doesn't use any debug info, remove it
- restructured the macros to add in NoDebug macro versions to className,
typeInfo. Might be helpful with tackling the globals bootstrapping issue.
- HashTableName + StaticHashTableName - avoid lookup of debug switch when
FULLDEBUG is not defined
- 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.
