Hi BRATs,
I've updated BRAT so that it may compile on Windoze 98, using
Micros**t Visual F**k++ version 6.0, using ROOT version 2.25/03. I
used the makeNT.bat script in the top BRAT directory.
I managed to compile almost all libraries, except Monitor, Mult (see
more below), Raw, and Online. makeNT.bat now creates as many libraries
as I found possible, and copies the header files to include before
compiling.
Several changes was needed in the code:
---------------------------------------
The most prevaling one, has to do with the s**tiness of MSVC++. That's
it's not ANSI compliant! In quite a lot of the methods, there's a
multiple use of the same loop variable, as in
MyClass::MyMethod() {
for (Int_t i = 0; i < 10; i++)
cout << "In first loop " << i << endl;
for (Int_t i = 0; i < 10; i++)
cout << "In second loop " << i << endl;
}
Even though this is plain ANSI (i has only scope of the each loop),
MSVC++ claims this is a multiple defintion of i (just how stupid is
that). To compile, using MSVC++, one has to do:
MyClass::MyMethod() {
In_t i;
for (i = 0; i < 10; i++)
cout << "In first loop " << i << endl;
for (i = 0; i < 10; i++)
cout << "In second loop " << i << endl;
}
or use different variable names! Please keep this in mind when
writting code that needs to be portable to Windoze (why one would
want to do that ************************* (blacked out)). This
doesn't only apply to the MSVC++ compiler; in fact KCC behaves the
same way, as well as some other commercial compilers. It's
interresting to observe in this context that the GCC is the most ANSI
compliant compiler on the market (and rumour goes that it creates the
fastest code)!
Other changes where in the lines of changing
#include <unistd.h> // UNIX C header
to
#include <stdlib.h> // ANSI C header
More on style:
--------------
1: Please do always use 'f' as the first character of mutable members,
'k' for constant members, 'g' for global variables, and 'fg' as
first two characters for static members.
2: Please use TString rather then std::string, or extensize use of
char arrays.
3: Please document your methods via inital comments in the method.
4: Any header (<class>.h) file should conform the following skeleton:
// -*- mode: c++ -*- For Emacs
//
// $Id$
// $Author$
// $Date$
//
#ifndef BRAT_<class>
#define BRAT_<class>
#ifndef ROOT_TObject // And similar for any class needed by the
#include <TObject.h> // header, wether it be a ROOT or BRAT class
#endif
class <class> <inheritance list>
{
<body of class declaration>
ClassDef(<class>,<version) // <Short description>
}
;
#endif
//
// $Log$
//
Where <class> is the name of the class.
5: Any implementation file (<class>.cxx) should conform to the
following skeleton:
//
// $Id$
// $Author$
// $Date$
//
//___________________________________________________________________
//
// <class Documentation>
//
#ifndef BRAT_<class> // And similar for any header file needed by
#include "<class>.h" // the implementation
#endif
//___________________________________________________________________
ClassDef(<class>);
//___________________________________________________________________
<class>::<class>(<args>) {
// method documentation
<body of method>
}
//___________________________________________________________________
<return type>
<class>::<method>(<args>) {
// method documentation
<body of method>
}
<and so on>
//
// $Log$
//
6: Make sure that every pointer that is allocated room for (via new)
is properly freed (via delete).
7: Do not use libc mathematical functions, rather use TMath. E.g.,
instead of
y = sin(x);
Do
y = TMath::Sin(x);
This is to insure portability. Also, don't use 3.141592653... or
#defines (including M_PI) for pi, but use TMath::Pi().
8: To recap what Flemming has previously stated about units:
Quantity Unit
-------------------------
Time nsec
Length cm
Energy GeV
Momenta GeV/c
Mass GeV/c^2
and I guess
Magnetic Field KiloGaus
An alternative would be to always use BrUnits for physical
quantaties e.g., 1000 * BrUnits::MeV == 1 * BrUnits::GeV
As to the mult directory:
-------------------------
The code in this directory needs a lot of tidying up. One really grim
example was the assigment of a member in the header file!
Also, in BrRdoModuleMult.h, there's alot of lines like:
Int_t fTileParam[kNumTilesChanMax];
This is not right. Please do something like:
Int_t* fTileParam; //[kNumTilesChanMax];
and then in the constructor
fTileParam = new Int_t[kNumTilesChanMax];
and in the destructor
delete [] fTileParam;
Then there's something like:
Int_t siOccupation[6][42];
This should probably be coded like
const int kRows;
const int kSiColumns;
const int kTileColumns;
Short_t* fSiOccupation; //[kNumSiChanMax]
And the then in the constructor, one can do something like
BrRdoModuleMult::BrRdoModuleMult(int)
: kRows(6), kSiColumns(42), kTileColumns(8) {
fSiOccupation = new Short[kNumSiChanMax];
// Set row = i, column j of Si active
fSiOccupation[i * kRows + j] = 1; // i = 0,.., 5; j = 0,...,41;
}
I've implemented these changes; since there was no $Id$ string, I
couldn't bug anyone (sig). Also, who ever wrotw that class in the
first place: You don't need a ';' after a for/while/if loops closing
brace '}'! And please observe the general naming scheme and still in
BRAT (members begin with 'f' for one).
BrRdoModuleMult contains a TNtuple and a TFile. That is very poor
practice. Rather, the class should write to some branch in the output
BrEventNode. No output files should ever be opened by any RDO module,
other then a designated one, since creating files behind the back of
the user only promotes confusion and chaos.
The TNtuple in BrRdoModuleMult is horrific! It has something like 320
columns! If something like an Ntuple is really needed, one should use
a TTree (perhaps passed down from special module) and write on some
branch of that TTree, via a special data class (similar to BrSiDig,
etc.)
Hito: In BrDigitzeMultTile::Init there's a loop over GeantFBConvTable
with hardcoded limits, please investigate and correct!
Yours,
Christian -----------------------------------------------------------
Holm Christensen Phone: (+45) 35 35 96 91
Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305
DK-2200 Copenhagen N Web: www.nbi.dk/~cholm
Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Fri Sep 22 2000 - 17:32:04 EDT