/** \page RM HDF5 Reference Manual The functions provided by the HDF5 API are grouped into the following \Emph{modules}:
Modules
\include{doc} core_menu.md
\include{doc} high_level_menu.md
\include{doc} fortran_menu.md
\include{doc} java_menu.md
Deprecated functions Functions with \ref ASYNC \ref api-compat-macros
Mind the gap
Follow these simple rules and stay out of trouble: \li \Bold{Handle discipline:} The HDF5 C-API is rife with handles or identifiers, which you typically obtain by creating new HDF5 items, copying items, or retrieving facets of items. \Emph{You acquire a handle, you own it!} (Colin Powell) In other words, you are responsible for releasing the underlying resources via the matching \Code{H5*close()} call, or deal with the consequences of resource leakage. \li \Bold{Closed means closed:} Do not pass identifiers that were previously \Code{H5*close()}-d to other API functions! It will generate an error. \li \Bold{Dynamic memory allocation:} The API contains a few functions in which the HDF5 library dynamically allocates memory on the caller's behalf. The caller owns this memory and eventually must free it by calling H5free_memory(). (\Bold{Not} the `free` function \Emph{du jour}!) \li \Bold{Be careful with that saw:} Do not modify the underlying collection when an iteration is in progress! \li \Bold{Use of locations:} Certain API functions, typically called \Code{H5***_by_name} use a combination of identifiers and path names to refer to HDF5 objects. If the identifier fully specifies the object in question, pass \Code{'.'} (a dot) for the name! Break a leg!
\cpp_c_api_note \par Don't like what you see? - You can help to improve this Reference Manual Complete the survey linked near the top of this page!\n We treat documentation like code: Fork the HDF5 repo, make changes, and create a pull request !\n See the \ref RMT for general guidance. */