Using c++ 1.8 API but CommonFG->openGroup not defined

I have old C++ code, written and compiled with V1.8 of HDF5. It’s for a 10 year old project that is still going but wanting to move to a newer system (Oracle 8, gcc 8.5). It’s a big project and I want to avoid any code changes. I’m looking to use a current HDF5 version and use the V18 API. I’ve downloaded 1.14.6, built it with -DDEFAULT_API_VERSION:STRING=v18 and compile with -DH5_USE_18_API. It still has a problem with the following:

/home/vance/buildtest/SPSFramework_n1/src/IO/hdf5_product.cpp: In member function ‘H5::Group* SMAP::FMWK::HDF5_PRODUCT::HDF5_open_group(H5::CommonFG*, const char*, bool)’:
/home/vance/buildtest/SPSFramework_n1/src/IO/hdf5_product.cpp:2198:36: error: ‘class H5::CommonFG’ has no member named ‘openGroup’; did you mean ‘openStrType’?
group = new H5::Group( fg->openGroup( “/” ) );
^~~~~~~~~
openStrType

When this didn’t work, I downloaded version 1.10.11 the same error occurs.

Looking at the include files I see that in 1.8 the openGroup function is in H5CommonFG.h:

[vance@smap-tb-n1 include]$ grep openGroup .
H5CommonFG.h: Group openGroup(const char *name) const;
H5CommonFG.h: Group openGroup(const H5std_string &name) const;

But in version 1.10.11 and 1.14.6 they are only in:

[vance@smap-tb-n1 include]$ grep openGroup .
H5Location.h: Group openGroup(const char *name) const;
H5Location.h: Group openGroup(const H5std_string &name) const;

Is there a workaround or do I have to update this part of the code?

Hi Vance, did the error occur if you didn’t use -DDEFAULT_API_VERSION:STRING=v18?

I will try that. Would that affect the include files created? I’m having the issue during the compile, not even got to the linking to the library part.

I’m not exactly sure which include files you referred to. All I did was taking an example in an HDF5 1.8 version and compiling it with a 1.14.5 h5c++ script (just something I had handy) and there was no error H5::CommonFG’ has no member named ‘openGroup’… The C++ API should be almost identical, if not identical, between 1.14.5 and 1.14.6. I tried that with -DH5_USE_18_API in case you need it.

How is the call to openGroup() in your example done? The two C++ examples in the 1.8 distribution that I can find and that use openGroup(), h5group.cpp and h5utr_crtgrpd.cpp have file->openGroup() or file.openGroup(), i.e. they are using openGroup in the H5::H5File class. What’s changed after 1.8 is that openGroup() is no longer in the abstract base class H5::CommonFG, which is the base class to both H5::H5File and H5::Group under 1.8.

I have a method that accepts a pointer to H5::CommonFG such that that you can pass a pointer to either an H5File or an Group object.
fg->openGroup( “/” ) where fg is H5::CommonFG*
no longer compiles under 1.10 or 1.14 with H5_USE_18_API. There’s a design note at the end of H5CommonFG.h about restructuring of classes. Perhaps this broke usage of openGroup().

In the version of H5CommonFG.h that comes with v1.8, in the include directory, it has…

class H5_DLLCPP CommonFG {
public:
// Creates a new group at this location which can be a file
// or another group.

// Opens an existing group in a location which can be a file
// or another group.
Group openGroup(const char *name) const;
Group openGroup(const H5std_string &name) const;

In H5CommonFG.h that comes with 1.14, under

class H5_DLLCPP CommonFG {
public:

there are no openGroup definitions.
The Design note says:
September 2017:

    This class used to be base class of H5File as well, until the
    restructure that moved H5File to be subclass of H5Group.

Ah! I see what the issue is. Yes, I was using h5group.cpp. The problem is H5::CommonFG was not intended for public creation of object. BTW, this archived 1.10.1 C++ API documentation announced its deprecation. I’m sorry but I don’t know of any way around it except changing to use H5Group in your the program.

The code doesn’t create an H5::CommonFG object. It has a method that accepts a pointer to either an H5::H5File or H5::Group object using their common base class (polymorphism). I could have two overloaded methods, one using H5::H5File and one using Group, or since I guess H5::H5File is now a derived class from Group, have the method use H5::Group.

Oh, ok, yes, your method could take an H5::Group instead of H5::CommonFG.