The functions provided by the HDF5 C-API are grouped into the following modules:

Modules

Mind the gap

Follow these simple rules and stay out of trouble:

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. You acquire a handle, you own it! (Colin Powell) In other words, you are responsible for releasing the underlying resources via the matching H5*close() call, or deal with the consequences of resource leakage.
Closed means closed: Do not pass identifiers that were previously H5*close()-d to other API functions! It will generate an error.
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(). (Not the free function du jour!)
Be careful with that saw: Do not modify the underlying collection when an iteration is in progress!
Use of locations: Certain API functions, typically called 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 '.' (a dot) for the name!

Break a leg!

Attention: C++ Developers using HDF5 C-API functions beware:
Several functions in this C-API take function pointers or callbacks as arguments. Examples include H5Pset_elink_cb(), H5Pset_type_conv_cb(), H5Tconvert(), and H5Ewalk2(). Application code must ensure that those callback functions return normally such to allow the HDF5 to manage its resources and maintain a consistent state. For instance, those functions must not use the C setjmp / longjmp mechanism to leave those callback functions. Within the context of C++, any exceptions thrown within the callback function must be caught, such as with a catch(…) statement. Any exception state can be placed within the provided user data function call arguments, and may be thrown again once the calling function has returned. Exceptions raised and not handled inside the callback are not supported as it might leave the HDF5 library in an inconsistent state. Similarly, using C++20 coroutines cannot be used as callbacks, since they do not support plain return statements. If a callback function yields execution to another C++20 coroutine calling HDF5 functions as well, this may lead to undefined behavior.

Don't like what you see? - You can help to improve this Reference Manual: Complete the survey linked near the top of this page!
We treat documentation like code: Fork the HDF5 repo, make changes, and create a pull request !
See the Reference Manual (RM) Page Template for general guidance.