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

Jason Kraftcheck kraftche at cae.wisc.edu
Tue Apr 13 13:59:18 CDT 2010


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.

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

- jason




More information about the moab-dev mailing list