blob: f1949e4ec3cc50e180099448fef5e4970ad7f41a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
/*! \mainpage API Documentation for HDF5 Version 1.13 (Draft)
*
* \todo Fix the search form for server deployments.
* \todo Make it mobile-friendly
*
* \section intro_sec Introduction
*
* \todo Write an introduction.
*
* \section quick_links Quick Links
*
* <ul>
* <li>\ref PDT "Predefined Datatypes"</li>
* <li><a href="https://portal.hdfgroup.org/display/HDF5/API+Compatibility+Macros">API Compatibility Macros</a></li>
* <li><a href="https://hdf5.wiki/">HDF5 Wiki</a></li>
* </ul>
*
* \section using_locations The Use of Locations (Identifier + Name) in the HDF5 API
*
* \todo Make this crystal clear!
*
* \section cpp_note Programming Note for C++ Developers Using C Functions
*
* If a C routine that takes a function pointer as an argument is called from
* within C++ code, the C routine should be returned from normally.
*
* Examples of this kind of routine include callbacks such as H5Pset_elink_cb()
* and H5Pset_type_conv_cb() and functions such as H5Tconvert() and H5Ewalk2().
*
* Exiting the routine in its normal fashion allows the HDF5 C library to clean
* up its work properly. In other words, if the C++ application jumps out of
* the routine back to the C++ \c catch statement, the library is not given the
* opportunity to close any temporary data structures that were set up when the
* routine was called. The C++ application should save some state as the
* routine is started so that any problem that occurs might be diagnosed.
*/
|
