1. 28 Jul, 2020 7 commits
    • Mark Olesen's avatar
    • Mark Olesen's avatar
      74a062d1
    • Mark Olesen's avatar
      BUG: potential memory leaks in HashPtrTable (#1787) · 65d640e5
      Mark Olesen authored
      - using HashPtrTable::set() with the same key twice did not guarantee
        proper cleanup of memory since it simply used the underlying
        HashTable::set() without doing anything about the old memory. Now
        check for pre-existing storage and delete it when it does not
        correspond to the newly stored pointer.
      
        This problem is independent of potential memory slicing previously
        flagged (#1286) and only partially resolved.
      65d640e5
    • Mark Olesen's avatar
      ENH: add get() retrieval of a pointer from PtrLists, HashPtrTable · fa71840d
      Mark Olesen authored
      - naming similarity with autoPtr, unique_ptr and other containers.
      
        For UPtrList derivatives, this is equivalent to the existing
        operator(). The read-only variant is also equivalent to the
        single-parameter 'set(label)' method.
      
        With PtrList<T> list(...) :
      
            const T* ptr = list.get(10);
            if (ptr)
            {
                ptr->method();
            }
      
        vs.
            if (list.set(10))
            {
                list[10].method();
            }
      
        For HashPtrTable there is only a read-only variant which is equivalent
        to testing for existence and for value.
      
        With HashPtrTable<T> hash(...) :
      
            const T* ptr = list.get("key");
            if (ptr)
            {
                ptr->method();
            }
      
        vs.
            if (list.found("key"))
            {
                // Fails on null pointer!!
                list["key"].method();
            }
      
      Use of get() is largely a matter of taste or local coding requirements
      fa71840d
    • Mark Olesen's avatar
      ENH: support emplace methods and std::unique_ptr for PtrList-derivatives · 872c9d37
      Mark Olesen authored
      - emplace methods
        Eg,
            m.internalCoeffs().emplace(patchi, fc.size(), Zero);
        vs.
            m.internalCoeffs().set(patchi, new Field<Type>(fc.size(), Zero));
      
      - handle insert/append of refPtr wherever tmp was already supported
      
      COMP: incorrect variable names in PtrListOpsTemplates.C
      872c9d37
    • Mark Olesen's avatar
      ENH: HashTable::emplace_set() method, HashPtrTable support for unique_ptr · 4110699d
      Mark Olesen authored
      - forwarding like the emplace() method, but overwriting existing
        entries as required
      
      - propagate similar changes to HashPtrTable
      
        For example, with HashPtrTable<labelList> table(...) :
      
        With 'insert' semantics
      
            table.emplace("list1", 1000);
      
        vs
            if (!table.found("list1"))
            {
                table.set("list1", new labelList(1000));
            }
        or
            table.insert("list1", autoPtr<labelList>::New(1000));
      
        Note that the last example invokes an unnecessary allocation/deletion
        if the insertion is unsuccessful.
      
        With 'set' semantics:
      
            table.emplace_set("list1", 15);
      
        vs
            table.set("list1", new labelList(15));
      4110699d
    • Mark Olesen's avatar
      COMP: fix sloppy (and now ambiguous) use of PtrList::set() · c77afff4
      Mark Olesen authored
      - constructs such as the following will no longer worked, but that is
        also a good thing.
      
           ptrlist.set(i, scalarField(nFaces, Zero));
      
        this called set(.., const tmp<scalarField>&), which meant under
        the hood:
      
           - create local temporary const scalarField&
           - wrap as const tmp&
           - use tmp::ptr(), to clone the const-ref
      
        This implies an additional allocation (for the const scalarField&)
        which is immediately discarded. Doubtful that compiler optimization
        would do anything.
      c77afff4
  2. 27 Jul, 2020 7 commits
  3. 24 Jul, 2020 1 commit
  4. 23 Jul, 2020 2 commits
  5. 22 Jul, 2020 2 commits
  6. 23 Jul, 2020 3 commits
  7. 21 Jul, 2020 2 commits
    • Sergio Ferraris's avatar
      BUG: Correct evaluate function for ddt0 in CrankNicolson scheme. Fixes · 45982d97
      Sergio Ferraris authored
      The function evaluate was returning true every outer loop, triggering
      the re-calculation of ddt0 in every outer loop.
      
      The evaluation of the term ddt0 should be performed once per time step.
      The corrected function updates the timeIndex of ddt0 to avoid the
      re-evaluation of this term in the outer loops.
      45982d97
    • Mark Olesen's avatar
      ENH: support writable reference for tmp (#1775) · be058bec
      Mark Olesen authored
      - improves flexibility. Can tag a tmp as allowing non-const access to
        the reference and skip additional const_cast in following code. For
        example,
      
            tmp<volScalarField> tfld(nullptr);
            auto* ptr = getObjectPtr<volScalarField>("field");
            if (ptr)
            {
                tfld.ref(*ptr);
            }
            else
            {
                tfld.reset(volScalarField::New(...));
            }
            auto& fld = tfld.ref();
      
      ENH: renamed tmpNrc to refPtr
      
      - the name 'refPtr' (reference|pointer) should be easier to remember
        than tmpNrc (tmp, but non-ref-counted).
      
      - provide tmpNrc typedef and header for code compatibility
      
      NOTE
      
      - in some places refPtr and tmp can be used instead of a
        std::reference_wrapper for handling external references.
      
        Unlike std::reference_wrapper, it can be default constructed
        (holding nothing), whereas reference_wrapper may need a dummy
        reference. However, the lifetime extension of references _may_ be
        better with reference_wrapper.
      be058bec
  8. 20 Jul, 2020 2 commits
  9. 17 Jul, 2020 2 commits
  10. 16 Jul, 2020 8 commits
  11. 15 Jul, 2020 2 commits
  12. 14 Jul, 2020 2 commits