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
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!)
On Fri, 23 Apr 2010 11:57:59 -0400, Dimitris Servis <firstname.lastname@example.org> wrote:
2010/4/23 Graeme Burnett <email@example.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