This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Roy, > I am working on trying to see if I can write some wrappers for > Fortran for my own use for the vlen and compound types in NetCDF4. > Working on the compound types, I was using the examples ad test code > as a basis, and I have several comments base don that. > > 1. Use of the compound type appears to depend on using HOFFSET, > which is an HDF5 call. Ideally, one should not need to know or > directly access HDF5 calls to use the netcdf4 library. I would > suggest adding an equivalent function, or a function that calls this > to the netcdf4 library so that it is self-contained and self-documented. Although HOFFSET is a macro defined in an HDF5 include file, it is actually the same as the "offsetof" macro defined in the C standard include file stddef.h, so you should be able to use "offsetof" instead. The C standard rationale says this about it: The offsetof macro has been added to provide a portable means of determining the offset, in bytes, of a member within its structure. This capability is useful in programs, such as are typical in data-base implementations, which declare a large number of different data structures: it is desirable to provide ``generic'' routines that work from descriptions of the structures, rather than from the structure declarations themselves. ... I think I agree with you that it would be better to document using "offsetof" instead of "HOFFSET", since then it doesn't look like an HDF5 call. Ed may have another opinion about this. Note that we can't just include a definition of offsetof in netcdf.h, as there is no single portable definition of this macro. The definition in stddef.h (or by a compiler) provides a version that works properly for each platform. > 2. The examples for compound types while clever and witty do not > really illustrate compound types or how you might use them. There is > little reason, as in the examples, to have a compound type with two > ints. It took me a while to be certain that the names that were > being given were to the i1 and i2 elements of the structure (I > believe this is correct) so if we view it as setting up a table with > fields of different types, these would be the row names of the table > - correct? If the example had different types of fields in the > structure, and the names of the elements in the structure reflect the > data, then it would be clearer. Real world type examples are both > clearer and provide better motivation for use of the feature. I agree that the documentation should use better examples. I am providing better examples in the ncdump test cases. See, for example, the following files in the ncdump directory of any recent snapshot: tst_comp.c ref_tst_comp.cdl Also, see the workshop for developers tutorial code for sea soundings in sections 13.9 and 13.10 of: http://www.unidata.ucar.edu/software/netcdf/workshops/2007/groups-types/index.html > Have a good holiday, Thanks, you too! --Russ