Skip to Content.
Sympa Menu

h5part - [H5part] attributes in H5hut

h5part AT

Subject: H5Part development and discussion

List archive

[H5part] attributes in H5hut

Chronological Thread 
  • From: Mark Howison <MHowison AT>
  • To: h5part AT
  • Subject: [H5part] attributes in H5hut
  • Date: Thu, 1 Jul 2010 11:00:05 -0700
  • List-archive: <>
  • List-id: H5Part development and discussion <>

In H5Part, we have a convention about function calls that there is a
separate call for each data type, for instance:


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:


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

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:


then have a switch to read the attribute:

case H5PART_FLOAT32 ... H5PartReadStepAttribFloat32

which is more complicated than if there were a many-type read function:

H5PartReadStepAttrib( ... type ... )

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?


Archive powered by MHonArc 2.6.19.

Top of Page