h5part AT lists.psi.ch
Subject: H5Part development and discussion
List archive
- From: Achim Gsell <achim.gsell AT psi.ch>
- To: Mark Howison <MHowison AT lbl.gov>
- Cc: h5part AT lists.psi.ch
- Subject: Re: [H5part] attributes in H5hut
- Date: Thu, 8 Jul 2010 13:23:36 +0200
- List-archive: <https://lists.web.psi.ch/pipermail/h5part/>
- List-id: H5Part development and discussion <h5part.lists.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
- [H5part] attributes in H5hut, Mark Howison, 07/01/2010
- Re: [H5part] attributes in H5hut, Achim Gsell, 07/08/2010
- Re: [H5part] attributes in H5hut, Mark Howison, 07/08/2010
- Re: [H5part] attributes in H5hut, Achim Gsell, 07/08/2010
Archive powered by MHonArc 2.6.19.