[MOAB-dev] Getting ent set data when tag_size > 1

[Tim Tautges]

Jason Kraftcheck wrote:
> Tim Tautges wrote:
>>
>> Jed Brown wrote:
>>> On Tue, 13 Apr 2010 08:15:07 -0500, Jason Kraftcheck
>>> <kraftche at cae.wisc.edu> wrote:
>>>> The iMesh interface has always been odd with regards to multi-value
>>>> tags.  Just use get/setEntSetData for all data types.
>>> There ought to be get/setEntSetArrData (in fact, I would only expose the
>>> array interface because the single-tag versions are crippled and not
>>> more usable).
>>>
>> Agreed.  I'll put that on the list of extensions to write, and will
>> propose it to itaps (nobody else really uses sets in any serious way, so
>> that's probably why it hasn't come up there).
>>
> 
> If you're going to propose changes, why not propose dropping the
> single-value versions entirely.  They are a legacy from the SIDL days that
> just confuse things (e.g. the current discussion.)  Really, all the
> type-specific get/set functions are legacy gunk from SIDL.
> 

Single-value versions are a bit easier when used from Fortran.  Still, I'd prefer to either get rid of them in favor of 
array-based functions on generic pointers, or keep the type-specific ones for arrays.  That would also allow single 
entity tag get for type-specific tags with more than one value, e.g. double[3].

>>> The values argument should also really be void* so that user code isn't
>>> required to cast to char* just so the implementation can do pointer
>>> arithmetic without casting.  The MPI standard also uses void* in place
>>> of void** to avoid requiring user casts (see the rationale for
>>> MPI_Comm_get_attr) and I would do this for similar uses in ITAPS,
>>> e.g. iMesh_getData.  My understanding is that ITAPS started with void*
>>> and changed, but I'm not aware of the rationale and find MPI's rationale
>>> to be quite cogent.
>>>
>> This is probably right, but I seem to remember considering that but not
>> being able to do it.  Jason, do you recall anything about that?
>>
> 
> This has nothing to do with pointer arithmetic in the implementation.  The
> decision to use char* was another legacy from SIDL.  The choice of 'BYTES'
> rather than 'OPAQUE' was fine and avoided confusion with the SIDL 'opaque'
> type.  Similarly using an array of 'chars' was the best choice for passing
> an array of bytes in SIDL (an array of 'opaque' was something quite
> different and a single opaque 'value' would have been inconsistent with the
> other functions.)  In C, while char or unsigned char is often used to
> represent a single byte, it is more common and more correct to use void* for
> an arbitrary contiguous sequence of bytes in memory.
> 

Aha, ok.  Then I'd agree that these should be void*.

- tim

> - 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