Feature memory containers

A fundamental cleanup of autoPtr, tmp and Xfer containers.

• modified the autoPtr to more closely resemble the interface and behaviour of std::unique_ptr, but with some legacy behaviour still available: a copy constructor that acts like a move constructor, a copy assign that acts like a move assign, a implicit cast to the underlying data type.

• modifying tmp to resemble std::shared_ptr is not easily possible or 100% desirable (we use it both for a shared_ptr behaviour and also to hold a const-ref of externally allocated fields etc).

• removed use of Xfer entirely, since it is now possible to accomplish the same with movable copy/assign (with lower overhead) or an autoPtr.

See issue #639 (closed)

changed the description

mentioned in issue #713 (closed)

I would bump the internal API number to 1803 to reflect the changes, but was also considering adding polyMesh constructors with Xfer back in (as a transitional convenience).

Comments from code review with @andy

• tmp::lvalue() method is indeed ugly, but still can't think a better name
• prefer to retain (nullptr) when constructing autoPtr - for documentation purposes
• Rename the From static to NewFrom for more clarity
• reset taking an movable autoPtr would be a nice modification, for code clarity.

--

• agreed on bump of API to 1803
• don't bother with transitional polyMesh construct from Xfer, since should not be encouraged and since creation of a mesh is fairly infrequent and thus only a few lines of code (can use #ifdef during transition).

Note (mis)features of autoPtr are tagged with conditional pre-processor defines:

#define Foam_autoPtr_copyConstruct
#define Foam_autoPtr_copyAssign
#define Foam_autoPtr_castOperator

Removing the castOperator behaviour is not a real problem. It only becomes an issue if passing an autoPtr to a function call that expects the underlying data type. This is non-dangerous, but is not very good coding practice.

Removing the copyAssign behaviour causes some problems when a class uses autoPtr for some members, but uses the default copy assignment. When copyAssign is removed, the default generation will fail.

Similar issues when removing the copyConstruct behaviour when a class with autoPtr uses the default copy constructor. There are many places in the code where this occurs. When the copy construct/assign are invoked, they are actually moving the data contents, which may not really be what is desired.

The copyConstruct also creates other interesting misfeatures. For example,

void someMethod(autoPtr<T> ap) ...;
autoPtr<T> myPtr = ....
someMethods(myPtr);

This invokes the copy constructor and triggers an undesired move.

added 12 commits

• c2d5f353 - ENH: cleanup, extend zero/one classes
• 608e5897 - ENH: added constexpr, noexcept for bool, Switch
• f4be59dd - BUG: incorrect cellId check in fvMatrix::setReferences()
• 0632690d - ENH: fvMatrix::setReferences() single value variant
• 5067ca7a - ENH: cleanup of ListOps, ListListOps. Adjustments to List, PackedList.
• 34ec9468 - ENH: dedicated HashSetOps, HashTableOps namespaces
• 7bedbeea - ENH: improvements for labelRange
• a2d43901 - ENH: cleanup autoPtr class (issue #639 (closed))
• 96d45486 - ENH: cleanup tmp class (issue #639 (closed))
• 35ed90b8 - STYLE: use autoPtr::New and tmp::New for simple return types
• ad33d01a - ENH: remove reliance on the Xfer class (issue #639 (closed))
• d527aca3 - CONFIG: bump API version number to 1803 to account for removal of Xfer

Compare with previous version

unmarked as a Work In Progress

added ~30 label

changed milestone to %v1806

assigned to @andy

Changes made as discussed. Interesting side note: by adding in the construct from std::nullptr_t and assign from std::nullptr_t (consistent with the unique_ptr and nicer for documentation), we get the following useful behaviour:

autoPtr<T> someMethod()
{
    T* p = nullptr;

    if (...) return p;   // Fails, constructor from pointer is explicit

    ... later

    return nullptr;     // OK, implicit construct from literal nullptr
}

This is quite arguable even clearer as to the programmer's intent, and certainly less noisy.

merged

By Andrew Heather on 2018-03-07T16:58:10 (imported from GitLab project)