The documentation pages in the reference manual for H5Z filter API is referring to an external page with an embedded PDF when talking about “HDF5 Dynamically Loaded Filters”. Can this document be converted into an actual doxygen documentation? It is as important as the H5Z* functions themselves and deserves the same level of accessibility.
Btw., it looks strange that herr_t H5Zregister() takes a void* as argument, but then the documentation specifies the argument needs to be an argument to the H5Z_class*_t structures. Wouldn’t HDF5 benefit from more type-safety in its API?
In principle, yes, but I’m not aware of a tool that can produce satisfactory results. To me, using Word & co in this context is like plastic pollution, and I can’t understand what beset The HDF Group to join the polluters. Sigh! Undoing the damage will take time…
… and have the compiler take away all the fun? No way!
It sounds like the right job for the one responsible for that pollution in the first place. After all, the description on how to do filter plugins is even more important than the H5Zregister() call since doing it as plugin is the preferable way, replacing the H5Zregistration() limited to a single application.
The coding team would be amazed what issues mere compilation of the HDF5 C library as C++ would find… I tried it once, its an interesting experience.
ah, more PDF’s linked. A good bunch of those RFCs looks outdated and ancient, so that RFC page looks like having optimization potential. But more importantly, if those RFC requests comments, where should and how should they be submitted? Wouldn’t it make most sense to have a dedicated thread in this forum to discuss them and have the documents linking to the respective forum threads?
All, here’s a take on full-text search. This is a brute-force complement to what comes with Doxygen out-of-the-box (upper right-hand corner). Let us know what you think! G.
holidays, we got a boatload of recent RFCs including: