itaps-parallel technical issues in iMeshP.h

[Jason Kraftcheck]

Devine, Karen D wrote:
> 
> 
>> On 10/3/08 12:20 PM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:
>>> Devine, Karen D wrote:
>>>> On 10/2/08 3:46 PM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:
>>>> iMeshP_destroyPartitionAll
>>>>   - Why is 'partition_handle' inout?  What is this function returning
>>>>     a handle to?  Some other partition?
>>> The partition handle should be set to an invalid value when we destroy the
>>> partition.
>>>
>> Why do we do this for partition handles, and not for any other type of
>> handle?  E.g.:
>>   iMesh_deleteEnt
>>   iMesh_deleteEntArr
>>   iMesh_destroyTag
>>   iMesh_destroyEntSet
>>   iMesh_endEntIter
>>   iMeshP_destroyPart
>> and for that matter:
>>   free
>>   delete
>>   fclose
>>   etc.
> 
> Actually, I would ask why ITAPS doesn't invalidate handles for other types
> of deletions (as in the list above).  As a user, I'd like to have a handle
> invalidated when it is no longer valid, so that I couldn't misuse it later.

For that to be useful, it requires the assumption that the application has
no more than one copy of the handle in question.  And when that is true, it
is rather trivial to set the handle to an invalid value after calling the
'destroy' function.

> And, yes, I wish "free" set its pointer argument to NULL after freeing
> memory.  So the true answer to your "why" question is that *I* wrote this
> section of iMeshP instead of other ITAPS people.  :)
> 
> Your example below is good, but in a C environment where users have to
> destroyPartition themselves, I think invalidating the handle is a good idea.
> In your example, you wouldn't have to send a temporary pointer to
> destroyPartition; you would only have to remove the "const" definition.

But that's exactly my point: I'd have to modify an unrelated part of my code
(the 'const') to use this function for no reason other than so that the
function can "invalidate" a variable that is about to be destroyed anyway.

>  The
> call to createPartition modifies the partition handle as well.  Wouldn't
> your class' constructor have to call createPartition?  If not, from where
> does the constructor get the partition handle?

Does it matter where it comes from?  Presumably it comes from some code that
does the partitioning, which is a bit to complex to put in a constructor.  I
can just as easily provide an example where the destructor doesn't destroy
the handle:

  class Partition {
  public:
     Partition( iMeshInstance instance, iMeshP_PartitionHandle handle )
       : myHandle(handle), myiMesh(instance) {}

     iMeshP_PartitionHandle get_handle() const
	{ return myHandle; }

     iMeshInstance get_mesh() const
        { return myiMesh; }

     private:
        const iMeshP_PartitionHandle myHandle;
        const iMeshInstance myiMesh;
   };


Now the management of the partition handle is "consistent" in that the
constructor does not allocate it and the destructor does not release it.
However, how I have to make a copy of the handle in the code that does
release the handle because I cannot do something like this:

  iMeshP_destroyPartitionAll( ptn.get_mesh(), ptn.get_handle(), &err );


- jason