Open Flamefire opened 8 years ago
one general comment: a current design flaw is still, that native HDF5 types such as hid_t
, hsize_t
, ... are currently exposed in the public API of libSplash (see e.g., CollectionType
, Dimensions
, Serial&ParallelDataCollector
, the new DCAttributeInfo
). This leads to the problem, that booth <splash/splash.h>
and <hdf5.h>
need to be present in user code.
Ideally, <hdf5.h>
and objects / types from it would not be visible in any of the user-included header files of libSplash.
HDF5 does datatype conversion when required (https://www.hdfgroup.org/HDF5/doc/UG/HDF5_Users_Guide-Responsive%20HTML5/index.html#t=HDF5_Users_Guide%2FDatatypes%2FHDF5_Datatypes.htm%23TOC_6_10_Data_Transferbc-26&rhtocid=6.5_2) So the interfaces should accept a
CollectionType
when reading making the read/write signature almost the same.Example:
If one is really interested in the actual collection type, there is the
readAttributeMeta
function. One could also make the type a pointer, with NULL allowed which would be handy for strings.