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

Reply via email to