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
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.
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.
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.
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.
Werner
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
