H5Part development and discussion

[Achim Gsell <achim.gsell AT psi.ch>]

On Jul 1, 2010, at 8:00 PM, Mark Howison wrote:

> In H5Part, we have a convention about function calls that there is a
> separate call for each data type, for instance:
> 
> H5PartWriteDataFloat32
> H5PartWriteDataFloat64
> etc.
> 
> But for the attribute API, we are not consistent with this, and there
> is a function
> 
> h5part_int64_t H5PartWriteStepAttrib          (       H5PartFile *     f,
>               const char *    name,
>               const h5part_int64_t    type,
>               const void *    data,
>               const h5part_int64_t    nelem   
>       )
> 
> where the type is specified using the flags
> 
>    * H5PART_FLOAT64 (for h5part_float64_t)
>    * H5PART_FLOAT32 (for h5part_float32_t)
>    * H5PART_INT64 (for h5part_int64_t)
>    * H5PART_INT32 (for h5part_int32_t)
>    * H5PART_CHAR (for char)
>    * H5PART_STRING (for char*)
> 
> At some point, I created functions for each type:
> 
> H5PartWriteStepAttribFloat32
> H5PartWriteStepAttribFloat64
> etc.
> 

I stumbled upon this a couple of days ago too ...

> I would like to propose that we remove the many-type function calls from 
> H5hut.

I agree!

> One potential issue is that users may have H5hut files that don't
> conform to some predetermined convention (e.g. the attribute "foo" is
> always a float32), and they need to query the attribute to determine
> its type:
> 
> H5PartGetStepAttribInfo(...)
> 
> then have a switch to read the attribute:
> 
> switch(type):
> case H5PART_FLOAT32 ... H5PartReadStepAttribFloat32
> etc.
> 
> which is more complicated than if there were a many-type read function:
> 
> H5PartReadStepAttrib( ... type ... )

It's not that simple. The user has to determine the size of the type and 
allocate an appropriate amount of memory.

> But we've clearly tried to establish a convention to get away from
> many-type functions, so I think we should continue in that direction.
> 
> Another option is to leave the query and many-type functions out of
> the high-level H5 API, but leave it in the h5core API for more
> advanced users.
> 
> What do others think?

We should change the attribute interface as you proposed but leave it in the 
h5core API.

Achim