+++ /dev/null
-//*CMZ : 1.00/01 04/07/97 16.43.13 by Nick van Eijndhoven (UU/CERN)
-//*-- Author : Nick van Eijndhoven (UU/CERN) 04/07/97
-
-This RALICE cmz file is an attempt to provide an Object Oriented framework,
-consisting of C++ classes, in which event reconstruction of the ALICE
-detector data can be performed.
-In switching to Object Oriented programming, I myself have started to
-perform the WA93 and WA98 data analysis within the ROOT [1] framework.
-Having seen the great advantages of this system I have started to make my
-C++ classes more general in order to use them as an onset for an ALICE
-reconstruction (and physics analysis) framework.
-The RALICE package can be compiled on all platforms using the GNU G++
-compiler and the various classes can be used in standalone mode.
-However, running the programs within the ROOT framework greatly enlarges
-the analysis capabilities (e.g. histogramming, fitting, graphics etc...).
-In addition the high level of interactivity of the ROOT/CINT system allows
-program development without the time consuming compile/link/load/execute cycle,
-whereas also the ROOT tree output format provides a completely machine
-independent data format providing efficient and easy to use data access
-capable to cope with the most complex data analyses programs.
-
-Only the (proposed) C++ ANSI standard is used in the source code and as
-such is fully compatible with all standard C++ compilers as well as with
-the ROOT/CINT interpreting system.
-
-The comments in the source code are placed in the locations proposed
-in the ROOT manual pages [1] such that the automatic source code
-documentation system of ROOT can be used directly from the source code.
-This has turned out to be very convenient (time saving) and guarantees
-always updated documentation compatible with the current source code.
-
-Coding conventions :
---------------------
-In order not to clash with the (class) names of the ROOT framework
-and (future) packages of other groups, a few rules concerning names
-of classes, (member)functions and variables have to be obeyed.
-The rules are the following :
-
- 1) Only (proposed) ANSI standard C++ is allowed, with an even stricter
- requirement that the code should compile without any warnings
- under the GNU g++, msvc++ and the native C++ compilers of HP
- and DECAlpha machines.
- This will assure the programs to run on all standard ALICE platforms.
- 2) Class names start with "Ali" followed by an uppercase character,
- all other characters are lowercase.
- Example : AliCalorimeter
- In this way the RALICE class names will NEVER clash with the ones
- of ROOT whereas the probability of a clash with the class names of
- other group's code (e.g. ATLAS, CDF, PHENIX etc...) is minimised.
- To prevent name clashes within the various (future) ALICE packages,
- please refer to the general note at the end.
- 3) Names of detector specific classes should start with "Ali" followed
- by the detector name in uppercase, all other characters are lowercase
- except the first character following the detector name, which has to
- be uppercase..
- Example : AliTPCSegment or AliPPCTiming.
- These detector specific classes should only be introduced when there
- is really a need for it.
- E.g. when a track segment of the TPC and ITS have a lot in common
- it would be better to introduce a general AliTracksegment class
- instead of AliTPCSegment and AliITSSegment classes.
- 4) Class headers should be under the control of "#ifndef" and the name
- should consist of "CLASSNAME_H" (i.e. the classname in uppercase).
- Example : #ifndef ALITRACK_H
- #define ALITRACK_H
- In this way also the ifdefs will be unique and prevents the danger
- of having the name of an ifdef being the same as a Classname.
- 5) The private area in the class header has to be defined as the last item.
- Macros, like the ROOT ClassDef() statement (if needed) must be put
- appear at the right location, i.e. just before the "};" of the
- class definition.
- 6) Names of member functions should start with a capital character
- and should NOT contain underscores (which drop out with HTML).
- From the name it should be clear what the functionality is and
- capital characters should be used to indicate various "words".
- Example : AliTrack::Set3Momentum(float* p)
- 7) Names of datamembers of a class should start with a lowercase "f"
- and the next character has to be uppercase.
- Example : float fEnergy
- This will allow directly identification of datamembers in the code.
- The names of all other local variables may be chosen freely by the
- author.
- Note : It is recommended to use only lowercase characters
- for local variables.
- 8) Names of global variables should start with "gAli" and the next
- character has to be uppercase.
- Example : gAliRun
- This will allow directly identification of global variables in the
- code and will not clash with the existing ROOT globals like
- for instance gDirectory etc...
- Note : Usage of global variables should be avoided as much as
- possible. Most of the data transfer should go via the classes
- and their member functions (data hiding).
- 9) Comments should be placed at the positions as outlined in the ROOT docs.
- This will enable the automatic HTML machinery of ROOT.
-10) Each class header should contain a short description of the class
- functionality including some examples.
-
-General note :
---------------
-Within the ALICE software pool it may happen that e.g. in simulation
-applications one wants to define for instance a Track class which
-contains as data members some additional information (e.g. which was
-the corresponding parent particle) compared to the AliTrack class.
-Since objects reconstructed from real data will always contain the
-minimal amount of information compared to e.g. objects from simulation,
-it is in the above case then necessary to introduce a new class
-AliSTrack (simulation track).
-Obviously such a newly defined object (AliSTrack) can be derived from
-the reconstruction object (AliTrack) and just have some data members
-and/or memberfunctions added to it.
-In such a way maximum flexibility is provided within every (future)
-ALICE project, whereas all produced data can always be analysed using
-the RALICE tools.
-In view of this it might even be preferred to impose as a convention
-for future projects to adopt a unique prefix for their specific classes.
-For example the prefixes "AliS" and "AliD" could be used to indicate
-the simulation and DAQ specific classes respectively.
-
-Installation :
---------------
-The RALICE library can be automatically installed using the automatic CMZ
-installation procedure.
-
-Available installation modes :
-------------------------------
-cmz -install ralice --> GNU G++ loadable libralice.a
-cmz -install ralice shared --> GNU G++ loadable shared library ralice.sl
-cmz -install ralice root --> ROOT (G++ based) loadable library ralice.sl
-cmz -install ralice - msvc --> MSVC++ loadable library
-cmz -install ralice shared msvc --> MSVC++ loadable shared library ralice.dll
-cmz -install ralice root msvc --> ROOT (MSVC++ based) loadable library ralice.dll
-cmz -install ralice - hpcc --> HP CC loadable library
-cmz -install ralice shared hpcc --> HP CC loadable shared library ralice.sl
-cmz -install ralice root hpcc --> ROOT (HP CC based) loadable library ralice.sl
-
-
-[1] http://root.cern.ch
-
-
-
- Nick van Eijndhoven
- Subatomic Physics Dept.
- Utrecht University/NIKHEF
- P.O. Box 80.000
- NL-3508 TA Utrecht
- The Netherlands
- Email: nick@phys.uu.nl
- WWW: http://www.phys.uu.nl/~nick
git://git.uio.no / u / mrichter / AliRoot.git / blobdiff