1. 11 Jan, 2009 1 commit
  2. 10 Jan, 2009 4 commits
  3. 09 Jan, 2009 9 commits
  4. 08 Jan, 2009 5 commits
  5. 07 Jan, 2009 2 commits
  6. 06 Jan, 2009 6 commits
  7. 05 Jan, 2009 7 commits
  8. 31 Dec, 2008 1 commit
  9. 07 Jan, 2009 2 commits
  10. 05 Jan, 2009 3 commits
    • Mark Olesen's avatar
      stringListOps - findStrings() with wordReList · cb65f1c7
      Mark Olesen authored
      - we can now use a list of words/regexp for filtering/selecting
        ... the first results: cellTable/boundaryRegion
    • Mark Olesen's avatar
      reworked regExp + wordRe a bit, minor change to keyType · 3c5852eb
      Mark Olesen authored
      - added optional ignoreCase for constructor.
      - the compile() methods is now exposed as set(...) method with an optional
        ignoreCase argument.  Not currently much use for the other regex compile
        flags though. The set() method can be used directly instead of the
        operator=() assignment.
      keyType + wordRe:
      - it's not clear that any particular characters are valid/invalid (compared
        to string or word), so just drop the valid(char) method for now
      - a bool doesn't suffice, added enum compOption (compile-option)
      - most constructors now have a compOption. In *all* cases it defaults to
        LITERAL - ie, the same behaviour for std::string and Foam::string
      - added set(...) methods that do much the same as operator=(...), but the
        compOption can be specified.  In all cases, it defaults to DETECT.
       In Summary
          By default the constructors will generally preserve the argument as
          string literal and the assignment operators will use the wordRe::DETECT
          compOption to scan the string for regular expression meta characters
          and/or invalid word characters and react accordingly.
          The exceptions are when constructing/assigning from another
          Foam::wordRe (preserve the same type) or from a Foam::word (always
    • Mark Olesen's avatar
      rename xfer<T> class to Xfer<T> · 19503c93
      Mark Olesen authored
      - 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.