#682 Minor bug in use of shared_ptr<> in mpicollectivecommunicationhh

Metadata

Property	Value
Reported by	Atgeirr Flø Rasmussen (atgeirr@sintef.no)
Reported at	Dec 4, 2009 20:30
Type	Bug Report
Version	Git (pre2.4) [autotools]
Operating System	Unspecified / All
Last edited by	Oliver Sander (oliver.sander@tu-dresden.de)
Last edited at	Dec 7, 2009 10:28
Closed by	Oliver Sander (oliver.sander@tu-dresden.de)
Closed at	Dec 7, 2009 10:28
Closed in version	Unknown
Resolution	Implemented
Comment	In dune-common 5750.

Description

There is a bug in the use of shared_ptr<>::operator->(). It attempts to use the operator to extract the underlying pointer, which is then checked. This fails because operator->() will not allow this (treats as an attempt to dereference a null pointer). A simpler check for null-pointerness is !ptr (using the conversion to unspecified-bool-type).

Also, one should use get() instead of operator->() to return the underlying pointer in other contexts (I have not made this change below, though).

Suggested fix:

--- dune/common/mpicollectivecommunication.hh (revision 5741) +++ dune/common/mpicollectivecommunication.hh (working copy) @@ -31,7 +31,7 @@ public: static MPI_Datatype get () {

```
if (type.operator->()==0)
```

if (!type)
  {
    type = shared_ptr<MPI_Datatype>(new MPI_Datatype);
    MPI_Type_contiguous(sizeof(T),MPI_BYTE,type.operator->());

@@ -85,7 +85,7 @@ public: static MPI_Op get () {

```
if (op.operator->()==0)
```

if (!op)
  {
    op = shared_ptr<MPI_Op>(new MPI_Op);
    MPI_Op_create((void (*)(void*, void*, int*, MPI_Datatype*))&operation,true,op.operator->());