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.
This supports the abstraction of the set of fields from the field code
generation macros making it easier to change the set of fields supported
by OpenFOAM. This functionality is demonstrated in the updated
fvPatchFields macros and will be applied to the rest of the field code
generation macros in the future.
- 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.
- Some commonly used write methods that are independent of
the calling context (ie, 2D/3D data, geometry, fields)
- Provide singleton null() for ensightFile, ensightGeoFile.
Can be used for MPI slaves that need a file reference for their
methods, but will never write to it, but it is also reasonable
to use an autoPtr with rawRef() for that as well.
to ensure 'patchType' is set as specified.
Required substantial change to the organization of the reading of the
'value' entry requiring careful testing and there may be some residual
issues remaining. Please report any problems with the reading and
initialization of patch fields.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2266
e.g. for the cavity tutorial the moving wall patch can be specified in
terms of the block vertices as before:
boundary
(
movingWall
{
type wall;
faces
(
(3 7 6 2)
);
}
.
.
.
or the new specification of the face as block 0, block face 3:
boundary
(
movingWall
{
type wall;
faces
(
(0 3)
);
}
