* Implement support for complex number datatypes
Adds the new datatype class H5T_COMPLEX
Adds the new API function H5Tcomplex_create which creates a complex
number datatype from an ID of a base floating-point datatype
Adds the new feature check macros H5_HAVE_COMPLEX_NUMBERS and
H5_HAVE_C99_COMPLEX_NUMBERS
Adds the new datatype size macros H5_SIZEOF_FLOAT_COMPLEX,
H5_SIZEOF_DOUBLE_COMPLEX and H5_SIZEOF_LONG_DOUBLE_COMPLEX
Adds the new datatype ID macros H5T_NATIVE_FLOAT_COMPLEX,
H5T_NATIVE_DOUBLE_COMPLEX, H5T_NATIVE_LDOUBLE_COMPLEX,
H5T_CPLX_IEEE_F16LE, H5T_CPLX_IEEE_F16BE,
H5T_CPLX_IEEE_F32LE, H5T_CPLX_IEEE_F32BE,
H5T_CPLX_IEEE_F64LE and H5T_CPLX_IEEE_F64BE
Adds hard and soft datatype conversion paths between complex number
datatypes and all the integer and floating-point datatypes, as well as
between other complex number datatypes
Adds a special conversion path between complex number datatypes and
array or compound datatypes where the in-memory layout of data is the
same between the datatypes and data can be converted directly
Adds support for complex number datatypes to the h5dump, h5ls and
h5diff/ph5diff tools. Allows h5dump '-m' option to change floating-point
printing format for float complex and double complex datatypes, as well
as long double complex if it has the same size as double complex
Adds minimal support to the h5watch and h5import tools
Adds support for the predefined complex number datatypes and
H5Tcomplex_create function to the Java wrappers. Also adds initial,
untested support to the JNI for future use with HDFView
Adds support for just the H5T_COMPLEX datatype class to the Fortran
wrappers
Adds support for the predefined complex number datatypes and
H5Tcomplex_create function to the high level library H5LT interface
for use with the H5LTtext_to_dtype and H5LTdtype_to_text functions
Changes some usages of "complex" in the library since it conflicts with
the "complex" keyword from the complex.h header. Also changes various
usages of the word "complex" throughout the library to distinguish
compound datatypes from complex datatypes.
This is where most people will expect to find license information. The
COPYING_LBNL_HDF5 file has also been renamed to LICENSE_LBNL_HDF5.
The licenses are unchanged.
Cleanup and prepare for thread-safety changes.
Big ideas:
* Wrap H5VL_class_t with H5VL_connector_t, so use of the class can be refcounted within the H5VL package, instead of relying on storing an ID within the H5VL_t struct and incrementing & decrementing the ID's refcount.
* Register H5VL_connector_t* for VOL connector IDs, instead of the H5VL_class_t*
* Stop other packages from rummaging around inside H5VL_connector_t and H5VL_object_t data structures, so that the H5VL package can change implementation details without coupled changes throughout the library
Small things:
* Simplified the coding for creating links
* Moved some routines into more logical locations
* Change name of libhdf5hl_fortran installed by autotools to libhdf5_hl_fortran to be
consistent with CMake install and with other hl lib files. Switched
corresponding symlink to libhdf5hl_fortran.
Fixes issue #4684.
* Update h5fc.in to use renamed libhdf5_hl_fortran.
Fix typo in code to create link to libhdf5_hl_fortran.a.
* Removed code to create symlink for previous name of renamed lib
libhdf5hl_fortran.
Add RELEASE.txt entry about changeing name libhdf5hl_fortran to
libhdf5_hl_fortran.
* Update missed line in h5fc.in for libhdf5hl_fortran name change to
libhdf5_hl_fortran. Fixes check-install failure.
* Change name of libhdf5hl_fortran installed by autotools to libhdf5_hl_fortran to be
consistent with CMake install and with other hl lib files. Switched
corresponding symlink to libhdf5hl_fortran.
Fixes issue #4684.
* Update h5fc.in to use renamed libhdf5_hl_fortran.
Fix typo in code to create link to libhdf5_hl_fortran.a.
* Removed code to create symlink for previous name of renamed lib
libhdf5hl_fortran.
Add RELEASE.txt entry about changeing name libhdf5hl_fortran to
libhdf5_hl_fortran.
Added functionality tests for the following APIs:
H5Rget_file_name
H5Rget_obj_name
H5Rget_attr_name
Also removed "+1" when returning a name length in H5R__get_attr_name().
The exter "+1" gave an incorrect value for the length of the referenced
object's attribute name.
Fixed GH-4447
* Fix Fortran test
The C API H5Rget_attr_name incorrectly added 1 to the length of the
referenced object's attribute name, so the Fortran API h5rget_attr_name_f
removed 1 from the returned value to accommodate the incorrectness.
This PR fixes H5Rget_attr_name so this workaround in h5rget_attr_name_f
is no longer needed.
* Add test H5Aget_name against H5Rget_attr_name
* Always use DECIMAL_DIG instead of LDBL_DIG. This was controlled by
an ifdef that is always true in C99 or greater
It's confusing to use float.h C constants as variable names in
configure.ac and the PAC_FC_LDBL_DIG macro.
* Directly compare MY_FLT128_DIG and MY_LDBL_DIG
* Make uniform across CMake and Autotools
* Don't export quadmath.h variables to H5pubconf.h
* Allow HDF5_LIB_INFIX to work with DLL
* Separate individual library name into parts and add suffix option
* Java cannot use alternative names and removed extra setting
* Incorporate the underscore into the CORE name
- Add Fortran H5R APIs:
h5rcreate_attr_f, h5rcreate_object_f, h5rcreate_region_f,
h5ropen_attr_f, h5ropen_object_f, h5ropen_region_f,
h5rget_file_name_f, h5rget_attr_name_f, h5rget_obj_name_f,
h5rcopy_f, h5requal_f, h5rdestroy_f, h5rget_type_f
- Fixed function H5Requal actually to compare the reference pointers
Fixed an issue with H5Requal always returning true because the
function was only comparing the ref2_ptr to itself.
* Correct the high-level library link
The link currently used points to 1.13 release. Changed to use the md file instead.
* Update Doxyfile for md files
* Update to include md files
* addressed issue wit promoted integers and reals
* fixed h5fcreate_f
* added option to use mpi_f08
* change the kind of logical in the parallel tests
* addressed missing return value from callback
* The issue was that the "allargs" variable was not being used in the final command of the compiler wrapper. Any entries containing an escaped quote (\", \') or other non-matching argument (*) would not be passed to the compile line. I have fixed this problem by ensuring all arguments passed to the compiler wrapper are now included in the compile line.
* added testing for compiler wrappers
