Hi Colin,
static class members are not streamed.
Note that you can remove several redundant statements in your program.
See below
Rene Brun
On Fri, 4 Oct 2002, Colin Bernet wrote:
>
> Hi Rene,
>
> I switched to root 3.03/09 (RH6.2), and my biggest problem is now solved
> : trees
> are now readable even if I don't have the original library. This is a
> great feature, and I thank you for that !
>
> Yet... I still have one last tiny problem : My program generates a lot of
> small trees that I have to chain together. As I noticed this process gets
> really slow when the number of files grows big, I wrote a small merge
> program :
>
>// #include "TROOT.h"<===============
> #include "MiniDST.h" // *
> #include "TChain.h"
>
> //extern void InitGui();<=====================
> //VoidFuncPtr_t initfuncs[] = { InitGui, 0 };<===================
> //TROOT root("simpleMP","DATE ROOTMonitorModule",initfuncs);<=========
>
> int main(int argc, char** argv) {
>
> if(argc < 3) {
> cerr<<"usage : MergeDST <source files> <output file>"<<endl;
> exit(1);
> }
>
> MEvent *event = new MEvent();
> TChain chain("MDST");
> chain.SetBranchAddress("event",&event); // *
> for(unsigned i=1; i<argc-1; i++) {
> cout<<"source "<<i<<" : "<<argv[i]<<endl;
> chain.Add(argv[i]);
> }
> cout<<"output "<<" : "<<argv[argc-1]<<endl;
>
> chain.Merge(argv[argc-1]);
>
> return 0;
> }
>
> I tried it with and without the star stamped lines.
>
> What is happening is that the StreamerInfo in the output files is not the
> same as the one in the input files. Some of the classes were removed in
> the merge process... these classes are almost empty, they just contain a
> static member, eg :
>
> class Particle {...};
>
> class Pi : public Particle {
> static double pdgmass;
> }
>
> I just want something really simple, just to get the pion mass when
> a pion is created. Otherwise everything needed is in the Particle class.
>
> Shouldn't this type of class also be included in the output's file
> streamer info ? Am I doing something wrong ?
> Right now, As the StreamerInfo is wrong, I cannot read at all the output
> file.
>
> thanks,
>
> Colin
>
>
>
> On Mon, 23 Sep 2002, Rene Brun wrote:
>
> > Hi Colin,
> >
> > Please indicate which version of Root and the platform?
> >
> > see below
> >
> > On Sun, 22 Sep
> > 2002, Colin Bernet wrote:
> >
> > >
> > > Hi rooters !
> > >
> > > Loading 2 shared libraries, each containing a dictionnary, or a single
> > > shared library containing 2 dictionnaries seems to be impossible. In the
> > > first case, symbols from the secodn library are not recognized by root,
> > > while in the second case, the created objects get stuck at one point for
> > > unknown reasons.
> > >
> > > What I want to do is :
> > > 1 - Fill trees (split 99) using classes located in lib1.so
> > > 2 - Use MakeClass on one of these trees, modify the code so it compiles,
> > > and create a shared library lib2.so out of that.
> > >
> >
> > This should work. Why do you have to modify the code to get it compiled?
> > please try version 3.03/09 in case you use older versions.
> >
> > > The only way to work that out was to create a library demo.so using
> > > TFile::MakeProject.
> > > in ROOT, I can then do
> > > .L demo.so
> > > .L lib2.so
> > > this works perfectly, despite the fact demo.so, to my point of view,
> > > should not be necessary to read a tree containing basic data types.
> >
> > Using version 3.03, you should be able to read/query a file containing
> > classes and not only basic data types, even if you do not have the
> > original class library.
> > >
> > > Now, I have some code in lib1.so that I would
> > > like to reuse in lib2.so. I tried to load these libraries in different
> > > orders, to link lib1.so as a module inside lib2.so, but nothing works. I'm
> > > afraid this is because 2 dictionnaries are conflicting.
> >
> > if lib2 depends on lib1, you should load lib1 first. I cannot tell you
> > more without looking at your classes.
> >
> > >
> > > One could argue that I may use unsplit mode so I get the objects from
> > > lib1.so as is inside the tree. I do not want to do that for 2 reasons : I
> > > prefer to keep the data independant from the source code by using basic
> > > types, and I like to be able to issue complex TTree::Draw commands
> > > to have a first look at the data.
> >
> > I repeat: You can analyze a Tree containing classes, even if you do not
> > have the original class library.
> >
> > Rene Brun
> >
> >
> > >
> > > Is there a way to solve this problem without duplicating the source files
> > > of lib1 to compile and link them in lib2 ?
> > >
> > > Many thanks,
> > >
> > > Colin
> > >
> > >
> >
> >
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:12 MET