On 27 April 2010 13:41, Werner Benger <[email protected]> wrote: > Hi Quincey, > > > On Tue, 27 Apr 2010 09:22:20 -0300, Quincey Koziol <[email protected]> > wrote: > > >> I've included comments below to address individual points, but I'd >> also like to introduce a new topic for discussion: how valuable are the >> current C++ wrappers to experienced C++ developers? I don't think they add >> much value, because the underlying C layer is reasonably object-oriented and >> is callable directly from C++. Would the user community be OK with >> deprecating them and opening the floor to a newer, community driven (and >> probably developed) set of C++ bindings? >> >> Quincey >> >> This is exactly the conclusion that I came to - another example of this kind of problem is with the MPI C++ bindings - they became deprecated because people didn't use them; the boost MPI library became a popular alternative.
> One conceptual question with the C++ wrapper is how to use extension > libraries to HDF5 that are using the C interface. If you want to use the C++ > API, but also some high-level C library on top of HDF5, then it one would > need to mix the C API usage and the C++ API, and it's just better to > directly stay at the C API then. > > Technically, it should be ensured that the C++ wrapper is merely a wrapper, > and doesn't introduce runtime overhead and more functionality rather than > improved syntax/semantic checking of correct usage for HDF5 objects. Using > type traits to map native C++ types or user-defined structures to HDF5 types > and object certainly needs to be part of it, that is just state of the art. > I disagree that it shouldn't add functionality; I think that where possible we should map C++ like constructs over the top of HDF5. I'd like to see a generator type interface that can dynamically fill a dataset from a function, and potentially having the dataset larger than the amount of memory on the node. Using HDF5 as the backend to a streaming interface such as http://stxxl.sourceforge.net/ to enable easy out of core processing using HDF5 would be a very attractive feature as a drop in replacement for in memory data structures. > On exceptions, I was reluctant on using them for a long time as well, in > particular as compilers had not been mature enough (such as to catch/throw > exceptions across windows DLLs has reportedly be a long-term problem), but > this situation appears to have changed and they are save to use nowadays. > Even more, they're even important to use, since the standard library throws > exceptions, for instance when out of memory during a new() call, or as part > of the standard template library. Exceptions have become unavoidable, and > C++ code just has to be exception-safe, which also requires some > reference-counting scheme using smart pointers, auto pointers and all this. > Exceptions are kind of key to the whole RAII idiom however it all depends upon your motivation for using C++; RAII is only one reason to use C++; for some people the type traits stuff for auto detection of datatypes is enough motivation to use C++; its possible to write a C++ API that only provides this functionality and leaves the resource management to the user as in the C interface. > > As a major anti-C++'ish design in the HDF5 library I see its iterator > concept - it requires one to define a callback routine, instead of having an > iterator object that can be incremented and allows to construct a for(;;) > loop over iterators, similar to STL iterators. But this is already based in > the HDF5 C library, if the HDF5 C++ wrapper tries to emulate iterators > through the HDF5 C callback function, it cannot be efficient, so that would > be something to be exposed on a deeper level. > > On a community driven development of a HDF5 C++ library - it might be > difficult, because there are just too many styles and flavors of how to use > C++. It would require at least one lead developer, or a group of lead > developers who are consistent in their C++ style and usage. > I did try to spark some interest around this a couple of months back; my code is available at http://github.com/jsharpe/hdf5. It'd be great to get a few more users of the library to help develop the interface a bit, my current developments are driven by requirements for a CFD solver in particular in parallel we will be doing independant IO so the API won't necessarily be sufficient for doing collective IO. I'd suggest that rather than trying to have a single lead developer that we use tools like github to manage forks and branches and iterate on the design by getting people to actually use it in their applications; the best interfaces will evolve when they fit the use cases of the users that are actually going to use the API. > > It might possibly be beneficial to just optionally compile all of the > current HDF5 C code as C++ - just for the sake of C++ being more critical on > many programming behaviors where C is sloppy about; various things that are > just warnings in C are errors in C++, so it could allow to catch some coding > problems. > There is little point to this; so long as we can include hdf5.h in a c++ compiled module without errors then is sufficient. James
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
