itaps-parallel technical issues in iMeshP.h

[Onkar Sahni]

> care of releasing them, etc.  Something like:
>   class Partition {
>     public:
>     Partition( iMeshInstance instance, iMeshP_PartitionHandle handle )
>       : myHandle(handle), myiMesh(instance) {}
>
>     ~Partition() {
> 	int err;
>         iMeshP_destroyPartitionAll(myiMesh, &myHandle, &err );
>     }
>
>     ...
>
>     private:
>        const iMeshP_PartitionHandle myHandle;
>        const iMeshInstance myiMesh;
>   };
>

   I do not know if iMeshP_destroyPartitionAll() is completely necessary
but above example doesn't make it clear either as I would ask why would
one call iMeshP_destroyPartitionAll() in ~Partition() (destructor) with
no call to iMeshP_destroyPartitionAll() in Partition() (constructor)?

class foo {
  public:
  foo(int *a) : acopy(a) {}
  ~foo() { delete [] acopy; }
  private:
  int *acopy;
};

int main(int argc, int *argv[]) {
  int *a_try = new int;
  foo foo1(a_try);
  delete a_try;
  return 1;
}

  a_try is not allocated in foo() but deleted in ~foo() and its not array.

- Onkar

>   class Partition {
>     public:
>     Partition( iMeshInstance instance, iMeshP_PartitionHandle handle )
>       : myHandle(handle), myiMesh(instance) {}
>
>     ~Partition() {
> 	int err;
>         iMeshP_destroyPartitionAll(myiMesh, &myHandle, &err );
>     }
>
>     ...
>
>     private:
>        const iMeshP_PartitionHandle myHandle;
>        const iMeshInstance myiMesh;
>   };










> The above code will not compile as is.  I want to declare the
> 'iMeshP_PartitionHandle myHandle' as const because I have no intention of
> changing it during the life of the object, but I cannot do so because
> iMeshP_destroyPartitionAll wants to clear the value when the object is
> destroyed.  I could, of course, work around this by making a copy of
> myHandle to pass into iMeshP_destroyPartitionAll, but why force people to
> work around the API.  Let the caller worry about clearing stale handle
> values if it wants to.
>
>
>>>   - Why the "All" in the name?  It isn't destroying all partitions,
>>>     just the passed one.  Presumably in the previous function 'All'
>>>     means the 'Mesh', but unless where destroying the Mesh in this
>>> function
>>>     it doesn't make sense from a consistency POV either.
>>
>> We used the convention "All" to indicate that all processes must call
>> the
>> function synchronously.  In this case, all processes in a partition must
>> agree to destroy the partition at the same time.  It would be bad for
>> some
>> processes to think a partition exists while other processes have
>> destroyed
>> it.
>>
>
> I think that "allDestroyPartition" (subject before verb) would be less
> confusing.  But maybe that's just me.
>
>>> iMeshP_getPartFromPartHandle
>>> iMeshP_getPartFromPartHandlesArr
>>> iMeshP_getPartHandleFromPart
>>> iMeshP_getPartHandlesFromPartsArr
>>>   - Should these be iMeshP_getPartIdFromPartHandle(sArr)
>>>                                   ^^
>>>        and iMeshP_getPartHandleFromPartId(sArr) ?
>>>                                        ^^
>>
>> Fine with me; they are probably clearer that way.
>>
>>
>>> void iMeshP_iPushTagsEnt
>>>   - If 'entities' is an input, it should be const.
>>
>> Shall do.  Are all input values supposed to be const?  Or just pointers?
>
> The pointers should be.  It doesn't really matter for other inputs.  For a
> pointer, specifying it const means that the calling function cannot change
> the pointed-to data.  For non-pointer (and non-reference args in C++)
> declaring the arg as const doesn't provide any meaningful guarantees to
> the
> caller.  The args are passed by copy.  They cannot be anything but "in",
> regardless of a 'const' designator.  If the argument is "in" then the
> caller
> shouldn't change it.  The C/C++ convention is to use const as necessary to
> force the "callee can't change it" part, implying the "in" property.
>
> - jason
>
>