libhdf5 c++ API will be dropped in HDF5 2.0

[rouault]

See this comment of HDFGroup/hdf5#5126 (comment) : "I should let you know that the C++ interface will be discontinued with HDF5 2.0.0, scheduled to be released in March, and there are much better alternatives exist, such as HighFive. Please consider that option."

I assume this will highly impact this project...

[petebunting]

Thanks @rouault. Yes, that is going to impact. @gillins, we should have a chat about how to migrate away from the C++ interface.

[gillins]

Yes thanks @rouault this is a pretty big blow for us - March is not very far away. @petebunting should we migrate to C or HighFive? Any chance you might have time over xmas to look into this? I have a bunch of other things I need to be doing, but will try and make some time.

[petebunting]

Hi @gillins. I might be able to put some time in during early January. My inclination is that it is probably best to go with the hdf c library as we're not building on a dependency. I've not heard of HighFive before, but it does look like a nice well developed interface which might produce easier to read code... What are your thoughts?

I've thought a few times over the years it probably would have been better if we had used the c library rather than the C++ when we first created libkea. The C++ library being an extra build option that most distributions don't build has been a pain at times.

[gillins]

@petebunting I agree that using the C library in the early days might have saved some stress, but I think HighFive is worth a look especially if it reduces the amount of boilerplate code we have. HighFive is header only so should be easier to install and we can even vendor it if necessary. I had heard whispers about HighFive before but never used it. Happy to follow your lead on this and whatever approach you think best.
Let's chat in January, hopefully I can make some time then too.

[petebunting]

@gillins I've had a bit more of a look at HighFive, and it would probably be easier than moving over to the C library, so maybe we should explore that a little more before making a decision. I think our code will be clearer and more maintainable using HighFive, but it is adding another dependency, which I am cautious of...

Either way, it should solve the weird exceptions error we're getting on MacOS, as I can't figure out what is causing that; I am pretty confident that it's not something we have done in the libkea code base.

[petebunting]

@gillins I've started a branch to make KEALib v2 built with the HighFive library. I've commented out much of the existing code to get it to compile and started porting functions. If you build and run 'test1', it'll generate a basic KEA file and read/write blocks of image data from the HDF5. There are quite a few debugging print lines in the code base, which I was going to leave until we've finished the port.

The HighFive documentation could be better, and the examples could be more aligned with what we need to do, but I think I have worked out the main functionality we need. I've found the JetBrains AI (from CLion) quite helpful for working out bits where the HighFive documentation wasn't clear.

The KEALib code base using HighFive is much cleaner, with fewer lines of code needed, compared to the HDF5 C++, so I think this is a good way forward.

See what you think...

[petebunting]

@gillins I was checking back on the original thread, and I noticed that 3 weeks ago, it was posted that they are going to keep C++ support in HDF5 v2 - HDFGroup/hdf5#5126 (comment)

Probably still worth porting to HighFive, but it takes the time pressure off.

[gillins]

Happy new year @petebunting ! Thanks for looking into this. I had a quick look and yes, it is much clearer now. I agree HighFive is the way to go. Are you happy working on this for now? I've got quite a lot on for the first part of the year but will be able to assist after that. Would be good to be off the C++ bindings as it does sound like they will remove them at some stage and there is that weird thing on OSX with recent versions.

Good that the time pressure is off, good noticing. Hopefully we can get this done without too much of a rush....

[rouault]

Hi. My little 2 cents. If vendoring HighFive within libkea, we cannot exclude that down in the consumer chain, someone else uses it too within their application, potentially at a different version. Is there a way to modify the C++ namespace so it is unique to libkea.
I've used many times a #define the_namespace_of_the_vendored_library gdal_the_namespace_of_the_vendored_library trick before including vendored headers.