Hi Quincey,
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
···
On 27 April 2010 13:41, Werner Benger <werner@cct.lsu.edu> wrote:
On Tue, 27 Apr 2010 09:22:20 -0300, Quincey Koziol <koziol@hdfgroup.org> > wrote: