1. 25 Mar, 2020 1 commit
  2. 31 Oct, 2019 1 commit
  3. 05 Nov, 2019 1 commit
  4. 03 May, 2019 1 commit
  5. 06 Feb, 2019 1 commit
  6. 30 Jul, 2018 1 commit
  7. 26 Feb, 2018 1 commit
    • Mark Olesen's avatar
      ENH: cleanup autoPtr class (issue #639) · 660f3e54
      Mark Olesen authored
      Improve alignment of its behaviour with std::unique_ptr
      
        - element_type typedef
        - release() method - identical to ptr() method
        - get() method to get the pointer without checking and without releasing it.
        - operator*() for dereferencing
      
      Method name changes
      
        - renamed rawPtr() to get()
        - renamed rawRef() to ref(), removed unused const version.
      
      Removed methods/operators
      
        - assignment from a raw pointer was deleted (was rarely used).
          Can be convenient, but uncontrolled and potentially unsafe.
          Do allow assignment from a literal nullptr though, since this
          can never leak (and also corresponds to the unique_ptr API).
      
      Additional methods
      
        - clone() method: forwards to the clone() method of the underlying
          data object with argument forwarding.
      
        - reset(autoPtr&&) as an alternative to operator=(autoPtr&&)
      
      STYLE: avoid implicit conversion from autoPtr to object type in many places
      
      - existing implementation has the following:
      
           operator const T&() const { return operator*(); }
      
        which means that the following code works:
      
             autoPtr<mapPolyMesh> map = ...;
             updateMesh(*map);    // OK: explicit dereferencing
             updateMesh(map());   // OK: explicit dereferencing
             updateMesh(map);     // OK: implicit dereferencing
      
        for clarity it may preferable to avoid the implicit dereferencing
      
      - prefer operator* to operator() when deferenced a return value
        so it is clearer that a pointer is involve and not a function call
        etc    Eg,   return *meshPtr_;  vs.  return meshPtr_();
      660f3e54
  8. 22 Nov, 2017 1 commit
  9. 14 Jul, 2017 1 commit
  10. 16 Mar, 2017 1 commit
  11. 03 Oct, 2016 1 commit
    • Mark Olesen's avatar
      ENH: provide direct access to raw pointer/reference from autoPtr (issue #252) · 96c3a090
      Mark Olesen authored
      All of the access methods for autoPtr include validity checks and will
      fail if the underlying point is NULL. In some cases, however, we'd
      like to retain the automatic deletion mechanism, but still address a
      nullptr. This is mostly for cases in which a file-stream should be
      allocated, but only on the master process. For these cases we'd still
      like to pass through and reference the underlying pointer (eg, to
      obtain the correct method call) without tripping the pointer check
      mechanism. If we attempt to use the ptr() method, the autoPtr memory
      management is bypassed and we risk memory leaks.
      
      Instead provide an alternative mechanism to obtain the raw underlying
      pointers/references. Use rawPtr() and rawRef() for these potentially
      useful, but also potentially dangerous, operations.
      96c3a090
  12. 28 Sep, 2016 1 commit
    • Mark Olesen's avatar
      ENH: provide refOrNull method for autoPtr. · 6d7ff59f
      Mark Olesen authored
      - Normally use '()' to deference. This has extra safety and issues a
        fatal error if the underlying pointer is not valid.
      
        However, in some cases we are happy with getting a null reference.
        The refOrNull() method returns the reference without any checking.
      
        Usage example:
      
            autoPtr<OFstream> osPtr;
            if (Pstream::master())
            {
                osPtr.reset(new OFstream(...));
            }
            writeViaMaster(osPtr.refOrNull());
      
            - The writeViaMaster() call takes an OFstream reference,
              but this is only used directly on the master.
              The slaves will pass things through to the master.
      6d7ff59f
  13. 05 Aug, 2016 1 commit
  14. 20 Feb, 2016 1 commit
    • Henry Weller's avatar
      Boundary conditions: Added extrapolatedCalculatedFvPatchField · 99a10ece
      Henry Weller authored
      To be used instead of zeroGradientFvPatchField for temporary fields for
      which zero-gradient extrapolation is use to evaluate the boundary field
      but avoiding fields derived from temporary field using field algebra
      inheriting the zeroGradient boundary condition by the reuse of the
      temporary field storage.
      
      zeroGradientFvPatchField should not be used as the default patch field
      for any temporary fields and should be avoided for non-temporary fields
      except where it is clearly appropriate;
      extrapolatedCalculatedFvPatchField and calculatedFvPatchField are
      generally more suitable defaults depending on the manner in which the
      boundary values are specified or evaluated.
      
      The entire OpenFOAM-dev code-base has been updated following the above
      recommendations.
      
      Henry G. Weller
      CFD Direct
      99a10ece
  15. 08 Nov, 2015 1 commit
  16. 26 Sep, 2013 1 commit
  17. 21 May, 2013 1 commit
  18. 14 Aug, 2011 1 commit
  19. 19 Jan, 2011 1 commit
  20. 14 Jan, 2011 1 commit
  21. 07 Jan, 2011 1 commit
  22. 05 Jan, 2011 2 commits
  23. 28 Jul, 2010 1 commit
  24. 21 Apr, 2010 1 commit
  25. 29 Mar, 2010 1 commit
  26. 10 Jan, 2009 1 commit
  27. 31 Dec, 2008 1 commit
  28. 17 Nov, 2008 1 commit
  29. 24 Oct, 2008 1 commit
  30. 16 Oct, 2008 1 commit
  31. 14 Oct, 2008 1 commit
  32. 25 Jun, 2008 2 commits
  33. 15 Apr, 2008 1 commit