GitLab

- Hash returns unsigned
- FixedList templated on unsigned int
- include uLabel.H in UList, HashTable etc. so the output function is know
  throughout

- make table power-of-two, but since it seems to give 1-2% performance
  improvement, maybe forget it too.

- remove two-argument form of hashing classes and do the modulus direclty
  within HashTable instead. This simplifies things a fair bit.

- migrate Hash<void*> from db/dlLibrary to primitives/hashes/Hash

- it was possible to create a PackedList::iterator from a
  PackedList::const_iterator and violate const-ness

- added HashTable::printInfo for emitting some information

- changed default table sizes from 100 -> 128 in preparation for future
  2^n table sizes

- much better performance on empty tables (4-6x speedup), neutral
  performance change on filled tables. Since tableSize_ is non-zero when
  nElmts_ is, there is no modulus zero problem.

http://openfoam.cfd-online.com/cgi-bin/forum/show.cgi?126/11287

- this allows SubField<point> for unallocated storage in PrimitivePatch

    - still not consistent for pd as does not include buoyancy effects

- 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.

while(runTime.loop())
{
...
}

idiom.

Demonstrated in the shallowWaterFoam solver.

- track previous time index and to avoid recalculating averages.
- make sure averages are up-to-date before calling write

- added end() method to functionObject, functionObjectList & associated classes
- moved outputFilters from src/sampling -> src/OpenFOAM/db/functionObjects

- 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.