Sorry. I hit reply to the wrong message and typed without looking, this email
was intended for the Cmake + HDF5 people and not the HDF5 users list. Apologies
for the noise.
JB
From: Biddiscombe, John A.
Sent: 31 March 2010 22:56
To: HDF Users Discussion List
Subject: RE: [Hdf-forum] HDF5 C++ library
My dynamic builds are all good (win/linux), but my static ones fail as some
libs have the suffix -static on the libs themselves, but the link line
doesn't. I'll be working on this tomorrow.
Question : Is this what we want (I'm trying to understand where the -static and
lib and _D prefix/suffixes should go). If someone compiles static, then make
install, then compiles dynamic and make install into the same location. We have
a problem with the FindHDF5 stuff. I don't understand quite what naming
convention you want. Do we want to allow the user to build static and dynamic
together (Boost does this yes?) if so perhaps then we can manage it. Either way
I would like to know what naming convention. Please correct below. thanks JB
Win32 :
Dynamic build
hdf5.dll (or do you want libhdf5.dll)
hdf5.lib (or do you want libhdf5.lib)
Dynamic Debug build
hdf5_D.dll (or libhdf5_D.dll)
hdf5_D.lib (or libhdf5_D.lib)
Static build
libhdf5.lib
Static Debug build
libhdf5_D.lib
linux:
Dynamic build
libhdf5.so
Dynamic Debug build
libhdf5_D.so
Static build
libhdf5.a
Static Debug build
libhdf5_D.a
From: [email protected] [mailto:[email protected]] On
Behalf Of James Sharpe
Sent: 31 March 2010 22:18
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] HDF5 C++ library
On 30 March 2010 18:34, Elena Pourmal
<[email protected]<mailto:[email protected]>> wrote:
James,
On Mar 29, 2010, at 2:08 PM, James Sharpe wrote:
I've begun writing a library in c++ with the purpose of easing use of hdf5 in
c++ with the stl. The source is available at:
http://github.com/jsharpe/hdf5
My reasons for doing this over the current hdf5 c++ bindings are thus:
* Lack of support for parallel MPI-IO (not currently implemented but will be
shortly!)
* Removal of necessity to construct manually dataspaces / datatypes when the
C++ type system can do the heavy lifting for you.
* Lack of support for hyperslabs
Could you please send us an example of "lack of support for hyperslabs" in C++?
I guess when I mean a lack of support for them I mean lack of a proper
abstraction. When you have a container of structures in C++ and you want to
fill one of the fields of the structure from a dataset in the file I want to be
able to say fill field x of this structure and create the appropriate dataspace
for me. I admit though that I haven't yet come up with a nice way of easily
specifying this in C++.
At this point we do not have funding to do any further development work on the
HDF5 C++ library. Easing use of HDF5 C++ library with stl was one of the tasks
we would like to do, but couldn't do due to the lack of resources. Our group
will be glad to provide some support for this work, especially if it comes as
an improvement/extension to the existing library since many of the HDF5 C++
users will benefit from this work.
My feelings are that the current level of abstraction provided by the library
is too low level. The MPI C++ bindings are kind of a good example of this; the
latest MPI standard has deprecated them because they are of little use - they
provided nothing above using the C api. The c++ bindings that most people use
is the boost library which provides a higher level abstraction of the API that
is more useful for interacting with C++ data structures.
The kind of things that I'd like to see support for in HDF5 is at a layer which
interacts closely with the stl and associated algorithms. An interesting
application might be to wrap a HDF5 dataset with the stl container concept to
enable streaming of processing of data in a similar vain to the stxxl library
but obviously with the benefits of the on disk format being hdf5. Being able to
overlap I/O and compute transparently without having to do the chunking myself
is a very desirable feature, and of course one of the compelling reasons to use
c++ because it lends its self to these kinds of abstractions very well.
I think the fact that people like Michael claim that people using c++ roll
their own functions around the hdf5 library shows that the c++ abstractions are
insufficient as they currently stand and could definitely be made more useful.
James
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org