itaps-parallel technical issues in iMeshP.h

[txie at scorec.rpi.edu]

I agree that the argument definition in iMeshP.h should be consistent in 
one way. And I think that the current argument definition trend in
iMeshP.h can be summarized as follows. (I agree with it. )

----------------------------------------
 If an argument is an 'in' argument (it will not be changed through the
function), it is a value not a pointer (except it is an 'array'
argument).

 If an argument is an 'inout' or 'out' argument (it can be changed through
the function), it is a pointer.
-----------------------------------------

 Through this way, User may be more clear about the interface function usage.

For example, in iMeshP.h, we have:

  iMeshP_createPart()
  iMeshP_destroyPart()
  iMeshP_createPartitionAll()
  iMeshP_destroyPartitionAll()
  iMeshP_syncPartitionAll()

Since the 'part_handle/partition_handle' argument is changed through the
function, it should be a pointer in the function argument list. (However,
the 'partition_handle' argument in iMeshP_syncPartitionAll() is not a
pointer now. )


PS:
One minor thing, in the latest iMeshP.h version,

  void iMeshP_getCopyOnPart(iMesh_Instance instance,
                    /*in*/ const iMeshP_PartitionHandle partition_handle,
                    /*in*/ const iBase_EntityHandle entity_handle,
                    /*in*/ const iMeshP_Part* part_id,
                   /*out*/ iBase_EntityHandle* copy_entity_handle,
                           int *err);

  To get one copy on a certain part, I think the 'in' argument 'part_id'
should not be a pointer.


  Please let me know if you have any problems. Thanks.


Ting



> IMO, the argument should be passed as an "in" argument, consistent with
> the dtor function to destroy the imesh instance.
>
> - tim
>
> Devine, Karen D wrote:
>> Despite what any of us prefer for deletion and destruction routines, we
>> should make iMeshP_destroyPartitionAll's behavior consistent with the
>> rest
>> of iMesh.  Let me know what's consistent, and that's what we will do.
>>
>> Karen
>>
>>
>> On 10/6/08 1:44 PM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:
>>
>>> 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
>>>
>>>
>>
>>
>>
>>
>
> --
> ================================================================
> "You will keep in perfect peace him whose mind is
>    steadfast, because he trusts in you."               Isaiah 26:3
>
>               Tim Tautges            Argonne National Laboratory
>           (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>           phone: (608) 263-8485      1500 Engineering Dr.
>             fax: (608) 263-4499      Madison, WI 53706
>
>