About c++ inside the hdf5 library

Hdf-forum archives
1

Having spent some time wading through the hdf5 source code whilst tweaking various things, I can't help feeling that much of the internal object id maintenance, list traversal, heap management and all the baggage that goes with the internal structures, would be vastly cleaner and easier to understand if stl containters/templates and c++ objects had been used when the library was first created.

I'm not wanting to convert the library or persuade anyone else to do so...but...

Do the hdf5 maintainers ever share the view that it would have been a much nicer library in general if it had been developed (at least internally and not the external visible interfaces) along such lines?

[PS. I don't want to start any big arguments about design choices, just wondering aloud about some of the internals].

thanks

JB

···

--
John Biddiscombe, email:biddisco @ cscs.ch

CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82

2

Hi John,

Having spent some time wading through the hdf5 source code whilst tweaking various things, I can’t help feeling that much of the internal object id maintenance, list traversal, heap management and all the baggage that goes with the internal structures, would be vastly cleaner and easier to understand if stl containters/templates and c++ objects had been used when the library was first created.

  That's probably true.

I’m not wanting to convert the library or persuade anyone else to do so...but...

Do the hdf5 maintainers ever share the view that it would have been a much nicer library in general if it had been developed (at least internally and not the external visible interfaces) along such lines?

  Yes, I think that's definitely the case. However, there wasn't a useful version of standard C++ available when we started the project, back in 1996. :-/ Right now, we must use internal conventions for lots of things that would be automatically handled in C++, but that's the best we can do in C...

  Quincey

···

On Apr 23, 2010, at 7:44 AM, Biddiscombe, John A. wrote:

3

John

You may find some useful insight here: http://www.tux.org/lkml/#s15

Section 3 has many cogent reasons not to use C++

Regards

Graeme

···

On 23 April 2010 15:39, Quincey Koziol <koziol@hdfgroup.org> wrote:

Hi John,
On Apr 23, 2010, at 7:44 AM, Biddiscombe, John A. wrote:

Having spent some time wading through the hdf5 source code whilst tweaking
various things, I can’t help feeling that much of the internal object id
maintenance, list traversal, heap management and all the baggage that goes
with the internal structures, would be vastly cleaner and easier to
understand if stl containters/templates and c++ objects had been used when
the library was first created.

That's probably true.

I’m not wanting to convert the library or persuade anyone else to do
so...but...

Do the hdf5 maintainers ever share the view that it would have been a much
nicer library in general if it had been developed (at least internally and
not the external visible interfaces) along such lines?

Yes, I think that's definitely the case. However, there wasn't a useful
version of standard C++ available when we started the project, back in 1996.
:-/ Right now, we must use internal conventions for lots of things that
would be automatically handled in C++, but that's the best we can do in C...
Quincey

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

--
Graeme Burnett
M: +447830368024
S: graeme.burnett

4

Although this refers to why they didn't do it at the time and why it's not
wise to do it for the kernel. Has little to do with a toolkit like HDF5.
Personally I don't mind about C or C++, you can rewrite all features of C++
using C and in the end the efficiency of the machine code is more or less
the same. It is mainly a matter of maintenance cost for THG. Maybe HDF6 will
be native C++?

Have a nice weekend

-- dimitris

···

2010/4/23 Graeme Burnett <rgb@enhyper.com>

John

You may find some useful insight here: http://www.tux.org/lkml/#s15

5

John

You may find some useful insight here: http://www.tux.org/lkml/#s15

Some of the reasons given there are quite recursive, though - "we don't
want a C++ linux kernel because there are no c++ drivers, and there are
no c++ drivers because there is no c++ support in the kernel".

But certainly true is the statement that the biggest danger of c++ is
its power, and one can do a lot of things wrong - more easily than in C -
when not knowing the many tricks in C++ that make it efficient. C is
like walking vs. C++ driving a car...

One problem of C++ is that it's not binary compatible across compilers;
one could not just install it on one machine and use it shared by all
applications, but each application that uses another compiler (including
different versions of g++) requires its own copy. Might or might not
be an issue.

Although this refers to why they didn't do it at the time and why it's not
wise to do it for the kernel. Has little to do with a toolkit like HDF5.
Personally I don't mind about C or C++, you can rewrite all features of C++
using C and in the end the efficiency of the machine code is more or less
the same.

Which is no longer true with more advanced features such as c++ exceptions,
that don't have a C counterpart.

It is mainly a matter of maintenance cost for THG. Maybe HDF6 will
be native C++?

Hm, HDF6 might imply another file format...

There had been discussions about ISO certification of HDF5, which would
require an independent implementation of the same functionality, so maybe
that could be a pure C++ version... (or Java, or Eiffel, or... yick!)

  Werner

···

On Fri, 23 Apr 2010 11:57:59 -0400, Dimitris Servis <servisster@gmail.com> wrote:

2010/4/23 Graeme Burnett <rgb@enhyper.com>

--
___________________________________________________________________________
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

6

There isn't going to be an HDF6 (at least as a file format change) - we think we've built in enough forward compatibility hooks that we can evolve the file format in whatever way is needed for the foreseeable future (i.e. at least the next 10-20 years). The implementation of the library that is used to access the files is mainly what we are focusing on here... :slight_smile: Personally, I think the [newish] 'D' language is a promising middle ground between C and C++.

  Quincey

···

On Apr 23, 2010, at 10:57 AM, Dimitris Servis wrote:

2010/4/23 Graeme Burnett <rgb@enhyper.com>
John

You may find some useful insight here: http://www.tux.org/lkml/#s15

Although this refers to why they didn't do it at the time and why it's not wise to do it for the kernel. Has little to do with a toolkit like HDF5. Personally I don't mind about C or C++, you can rewrite all features of C++ using C and in the end the efficiency of the machine code is more or less the same. It is mainly a matter of maintenance cost for THG. Maybe HDF6 will be native C++?

7

I wrote a C++ library to create our implementation/schema of HDF5 for data. It was much, much easier to implement than it would have been to do it in C, and easier to understand and maintain. However, when someone wants to use Java, or COM or <insert language here>, it would be much easier for them to wrap a C library than C++, and they go off and write their own implementation of the file spec. I don't know if this is the case on all operating systems, but in Windows it is a lot easier to wrap a C library for use in other languages. I have a feeling that if HDF5 had been written in C++ rather than C, the Java port and the third party Python implementations would probably not exist.

George Lewandowski
(314)777-7890
Mail Code S270-2204
Building 270-E Level 2E Room 20E
P-8A

···

________________________________
From: hdf-forum-bounces@hdfgroup.org [mailto:hdf-forum-bounces@hdfgroup.org] On Behalf Of Dimitris Servis
Sent: Friday, April 23, 2010 10:58 AM
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] About c++ inside the hdf5 library

2010/4/23 Graeme Burnett <rgb@enhyper.com<mailto:rgb@enhyper.com>>
John

You may find some useful insight here: http://www.tux.org/lkml/#s15

Although this refers to why they didn't do it at the time and why it's not wise to do it for the kernel. Has little to do with a toolkit like HDF5. Personally I don't mind about C or C++, you can rewrite all features of C++ using C and in the end the efficiency of the machine code is more or less the same. It is mainly a matter of maintenance cost for THG. Maybe HDF6 will be native C++?

Have a nice weekend

-- dimitris