Hi Russ,
> > I think supporting creation order for attributes might be a bit
> > more of a problem than for the other kinds of objects, but from
> > reading your description of the attribute number below, it doesn't
> > look like it's a real problem if the "creation order" of attributes
> > changes. Is that so?
>
> Oops, I realize I didn't actually answer the question. The netCDF
> interface (for mostly historical reasons that are hard to justify now)
> permits deleting attributes but not deleting variables or dimensions.
> So attribute numbers can change if you delete preceding attributes,
> but that doesn't change the order of remaining attributes. The only
> way to change the attribute order would be to delete an attribute and
> then later re-add it at the end, but doing that would have to be
> intentional, so the new order is still preserved.
Ok, I reviewed our code for attributes and we are already handling them
in a manner which preserves the creation order, so that shouldn't be a
problem. (I did add a note to write a unit test that verifies that this
continues to be so, also :-)
Quincey
>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 17 2003 Nov -0700 07:19:56
Message-ID: <wrxy8ufjcvn.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 17 Nov 2003 07:19:56 -0700
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: Quincey - Question about character
Received: (from majordo@localhost)
by unidata.ucar.edu (UCAR/Unidata) id hAHEJwvq003284
for netcdf-hdf-out; Mon, 17 Nov 2003 07:19:58 -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 hAHEJvOb003280
for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Mon, 17 Nov 2003 07:19:57 -0700 (MST)
Organization: UCAR/Unidata
Keywords: 200311171419.hAHEJvOb003280
Lines: 13
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
Howdy Quincey!
Is it the intention that the HDF5 type H5T_NATIVE_CHAR for ASCII
strings, H5T_NATIVE_UCHAR for unsigned byte data, and H5T_NATIVE_SCHAR
for signed byte data?
I'm suprised and very happy if so, because it would be very handy for
me to have a type for ASCII data which is different from signed char
data.
Thanks,
Ed
