From firstname.lastname@example.org Fri Mar 19 17:23:31 1993
From: email@example.com (Leif Loennblad)
Subject: C++ Class Library for High Energy Physics
Date: Fri, 19 Mar 1993 17:36:49 GMT
Development of a common C++ Class Library for High Energy Physics
I'm writing this letter to everyone I know of in the High Energy
Physics community, who are in some way interested in or using C++. If
there is someone else you know of that may be interested this letter,
please feel free to re-distribute it.
At the 'Computing in High Energy Physics' conference last year in
Annecy, an informal group met to discuss the development of a common
C++ class library for HEP. There it was agreed that, as more and more
people in our community are starting code development projects in C++,
it is necessary to develop such a class library, to facilitate the
interaction between future programs and to prevent the re-invention of
too many wheels.
Many things were discussed during this meeting, but not much was
decided, mainly because the group was rather small and didn't by far
represent the whole HEP-C++ community. As far as I can see, only two
major decisions were made:
(1) As it is very important for the success of this class library, that
as many potential users as possible may have the chance to influence
its design, it was decided that the forum for discussions should be a
HEPNET news group (hepnet.lang.c++).
(2) To get these discussions going, I was supposed to submit some of
the base classes that have been written for the MC++ project.
In December I fulfilled this assignment and posted a small package,
which I called CLHEP, to hepnet.lang.c++. Unfortunately the
anticipated discussion didn't start. I'm not really sure why. Maybe it
wasn't clear to people that my CLHEP package was just a starting point
for discussions and not a 'take it or leave it' proposal. Maybe people
does't know how to read or post to the hepnet.lang.c++ news group.
Maybe the classes I submitted were so bad they were beyond critique...
In any case, it is now late March and this time I'm determined to
start a discussion.
There are a number of questions that I feel are essential to discuss:
* Do we really need this?
My answer is (of course) YES! Maybe this is not a very interesting
question - if you don't agree you probably have stopped reading by
* Who should decide what the library should look like and what should
be in it? How shall the development proceed? Who should write the
I think it is important that anyone interested should have the
possibility to influence. Therefore I think it is a good idea to use
the publicly available HEPNET news group, both for the discussions
and for the decision process (simply through voting). It may be naive
to think that a full scale programming project can be administered in
this way, but I really think that it is the best place to start. Of
course, if it doesn't work out, we will have to find another way.
My idea of how the development should proceed is the following. First
there will be a period of discussion about the general features of
the library (coding standards, which classes should be in it etc.).
During this time a hand full of people will be chosen to administer
the actual source code (yes I volunteer to be a part of this group).
Ideally each person in this group will be responsible for a set of
classes. Then there will be a period where details of the code is
discussed. Some new classes may appear others will disappear. People
will try out the code and suggest modifications. I assume that anyone
criticizing the code also will have constructive suggestions on how to
modify it. I also assume that anyone proposing addition of classes is
prepared to write some of the code himself.
* Which platforms should be supported?
Any UNIX platform with the gcc version 2.3.3 or later. And, of course,
as many others as possible. Again I assume that any suggestion of
additional platforms to support will be accompanied by an offer to
help with the porting work. For the code I submitted I used the
autoconf program from GNU, and although I don't really understand all
the features of this program yet, it seems to be a very good tool for
simplifying the porting procedure.
* What should be in the class library.
During the meeting in Annecy we discussed the following categories:
1) Math classes: three-vectors, four-vectors, matrices etc.
2) Data/Object Management classes: container classes, etc.
3) I/O classes...
The code that I submitted pretty much represent which classes I want
to have in it: a list class and a corresponding iterator class, a
character string class, a random number generator class, three-vectors
and Lorentz vectors with corresponding rotation classes. Other classes
I would like to see is a _very_ basic particle class and classes to
handle persistent I/O of objects. It is important to realize that the
ANSI/ISO committee for C++ will specify some standard classes. It is
not clear yet which these will be, but a character string class will
certainly be among them and probably also a list class.
* How about coding standards and naming conventions?
This will probably cause a lot of discussions. I would propose that
the nitty-gritty details such as where to put the braces should be
left to the individual code writer to decide. Other things like naming
conventions has to be discussed. If you look in the code I have
submitted you will see the style I use at the moment, but I have no
religious opinions on the matter. You will also find that I use a
special way of writing comments which are suitable to be parsed by the
'classdoc' program which produce Unix-style manual pages from header
files. This I have found to be a very practical way of getting
rudimentary documentation for the code I write.
As far as the general philosophy is concerned, my opinion is that
this class library should be very light weight. No one should
hesitate to use it because it contains too much stuff not needed for
his application. Also the size of the classes should be as small as
possible, and the member functions should be as few and as fast as
possible. If someone needs some more functionality, he can easily
obtain that through inheritance.
* How should the code be distributed during the development phase?
First I submitted my classes as a 'shar' file to the hepnet.lang.c++
news group, but I do not think this is a good solution. Instead I have
arranged with the people in charge of the freehep data base to create
an area called hep-projects accessible via anonymous ftp, to be used
by projects like this one. This now exist, and you can get my initial
CLHEP suggestion by anonymous ftp to freehep.scri.fsu.edu in the file
hep-projects/CLHEP/CLHEP-0.04.tar.Z. So far it is not possible for
everyone to put code in this directory, so if you have something to
place there you should send it to me and I'll do it for you.
OK, I think that is enough for now. It's now time for you to say what
you think. But I must ask you NOT to send any personal e-mail to me.
If you have anything to say, you should post an article to
hepnet.lang.c++. If you don't know how to read or post articles on
hepnet news groups, you should ask your system manager (if he doesn't
already know, it's his job to find out...). If everything else fails,
you may send me an e-mail with your opinions and an explicit
permission for me to forward the message to hepnet.lang.c++. Also if
you can't access hepnet news groups at all, the articles in
hepnet.lang.c++ are available through anonymous ftp to
freehep.scri.fsu.edu in the directory news/hepnet/lang/c++.
Finally I would just like to say a few words about myself, for those
of you who don't know me.
My name is Leif L"onnblad and I'm from Sweden. I got my PhD in Lund a
couple of years ago where I was working with stuff related to the Lund
model. I'm currently working as a post-doc at the DESY theory group,
but will move to CERN after the summer. My main interest is QCD
phenomenology but I have also been working with neural network
applications. I am the (co-) author of two fairly well known Fortran
programs; the Ariadne event generator for simulating QCD-cascades
according to the colour dipole model, and the neural network program
JETNET. Two years ago I became interested in object-oriented
programming and started up a project for writing a C++ toolkit for HEP
event generation called MC++.
Leif Lonnblad, DESY (-T-), Notkestr. 85, 2000 Hamburg 52, FRG
phone: +49-40-8998-2048, fax: +49-40-8998-2777