Hello all,
On Wed, Mar 16, 2011 at 08:08:34PM +0100, Ian Hinder wrote:
An alternative would be to introduce two additional thorns, HDF5Fortran and HDF5CPP, which are each responsible for adding the appropriate libraries to HDF5_LIBS. I don't like this solution though.
I don't think we need to go that far. As far as I know the only tool using the c++ interface is the visit reader, and Christian agreed to rewrite it to use the C interface instead - and more related to Cactus itself EOS_Omni table reader, which uses the Fortran interface. I changed a similar routine in another code from using fortran to C, and someone (Roland?) already did that once for EOS_Omni.
I wrote C wrappers for the HDF5 functions (ie H5Dread mostly) that EOS_Omni uses (see https://trac.einsteintoolkit.org/ticket/145). They are not what you would call portable routines, but they try to at least fail loudly if their assumptions are violated (namely that any HDF5 handle returned fits in a CCTK_INT). The reason for not rewriting the actual routines that uses HDF5 was that that routine also uses Fortran 90's "allocate" to allocate an "allocatable" array (alltables in the module eos_module). Since I don't know how to do this allocation in C, I would have had to write at least two routines: * a Fortran one that does the allocate and returns a pointer to it * a C one to read in all the hdf5 datasets, call the Fortran routine with the sizes read from the file, and fill in the newly allocated table.
Yours, Roland