NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Quincey,
> My current idea is to add a "creation time" piece of metadata to each
> object as it is created in the file, and then the H5Giterate() call (or
> something resembling it) could choose whether to use creation times or the
> object names (or last modification times, etc.) as the method of indexing the
> objects to iterate over. Fairly simple and straightfoward, I think...
Even simpler would be a "creation sequence number" piece of metadata.
This would just be an integer that incremented for each new HDF5
object, or maybe several such sequences for different kinds of
objects.
There are some advantages of sequence numbers over times:
- you don't have to worry about clock resolution and the possibility
that creation times of two objects are equal
- you can use gaps in the sequence numbers to tell that objects have
been deleted, something not possible with times
- adding 1 is cheaper than the system call necessary to access the
system clock
- in distributed systems, there is not necessarily a well-defined
time ordering for events (only a partial ordering)
I don't foresee any need for knowing the actual creation time of a
netCDF-4 object, but if there are other applications for this kind of
information, than feel free to ignore this suggestion ...
--Russ
>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 12 2003 Nov -0700 10:31:32
Message-ID: <wrxptfxbiiz.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 12 Nov 2003 10:31:32 -0700
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: error handling with HDF5...
Received: (from majordo@localhost)
by unidata.ucar.edu (UCAR/Unidata) id hACHVXoO001169
for netcdf-hdf-out; Wed, 12 Nov 2003 10:31:33 -0700 (MST)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu
[128.117.140.88])
by unidata.ucar.edu (UCAR/Unidata) with ESMTP id hACHVWOb001157
for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Wed, 12 Nov 2003 10:31:32 -0700 (MST)
Organization: UCAR/Unidata
Keywords: 200311121731.hACHVWOb001157
Lines: 35
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk
Quincey,
Unfortunately, all your example code has little or no error handling
of HDF function calls. For example, from h5_compound.c:
/*
* Create a data type for s3.
*/
s3_tid = H5Tcreate(H5T_COMPOUND, sizeof(float));
status = H5Tinsert(s3_tid, "b_name", 0, H5T_NATIVE_FLOAT);
/*
* Read field b from s1 dataset. Field in the file is found by its name.
*/
status = H5Dread(dataset, s3_tid, H5S_ALL, H5S_ALL, H5P_DEFAULT, s3);
In this code, the return values are never even checked for anything.
Could you post some HDF5 which has some more complex error handling?
For example, handling a case of opening a bunch of HDF5 objects,
handling an error somewhere in the middle of it all, and still closing
the already opened HDF5 object before exiting the function.
Our new programmer, Dan, told me that I shouldn't be using goto in
C. I decided to ask to see some code from you, rather than launch into
a long and (believe me) very boring rant about how when I was a boy,
and gotos were first invented, and 25 cents was a lot of money, blah,
blah, blah. ;-)
Thanks!
Ed
netcdf-hdf archives: