Hi Christian, I found your answer about STL in ROOT I/O ambiguous. You do not have to encapsulate STL members in a class derived from TObject. By the way, a class does not need to derive from TObject to be persistent. A class must derive from TObject, if: - you want to do obj.Write() - you want to create a top level branch of a Tree. At URL: ftp://root.cern.ch/root/bigevent.tar.gz you will find a short (but complex) example that I use regularly to test ROOT I/O. The Event class includes many members that are STL containers and it also uses classes not derived from TObject. This example is an extension of the standard example in $ROOTSYS/test/Event. Rene Brun Christian Holm Christensen wrote: > > Hi, > > On Tue, 08 Jan 2002 15:30:10 +0000 > Rene Brun <Rene.Brun@cern.ch> wrote > concerning "Re: [ROOT] TGraph and vector": > > Hi Colin, > > > > Colin Bernet wrote: > > > > > > Hi Michael, > > > > > > As root was not compiled with STL (why not, Rene ?), > > > > What do you mean by "compiled with STL" ? > > That is indeed a good question. I'll try, for the sake of clarity to > say a few words on STL and STL and ROOT. > > Usually, STL is implmented as a set of header files - that is, there's > no compiled code in an STL distribution. That is because of the 'T' > in STL: If you want to make instantions of a template class, you need > the full implementation. Hence, you can not "compile in" STL support > in the ROOT libraries. What one can compile in (sometimes) are the > specific instantations of a template, like for example > vector<TObject>. > > Now, since it's not possible to "compile in" STL into the ROOT > libraries, what one does need, is for the CINT parser to understand > templates. That is both the dictionary generator (rootcint or > makecint) and the interactive tool (root or cint) need to understand > code like > > template <class T> class MyTemplate { > > as well as as > > class IntVector : public TObject { > private: > typedef vector<Int_t> Vector; > typedef vector<Int_t>::iterator Iter; > > Vector fVector; > Iter fIter; > public: > ... > > But this has nothing to do with "compiling in" STL support. It's > merely (well, it's not easy) a matter of writting the parser and > lexer, and the dictionary generating code. Now Masa has in his > infinit wisdom decided to ship CINT with a number of pregenerated > dictionaries for STL classes, so that we (the unworthy users) do not > need to that. Just try and do > > prompt> cint > cint> #include <vector> > cint> vector<int> v > > However, you can also do > > prompt> root > root [0] #include <vector> > root [1] vector<TString*> v(10, 0); > root [2] v[0] = new TString("s1"); > root [3] v[1] = new TString("s2"); > root [4] v[2] = new TString("s3"); > root [5] vector<TString*>::iterator b = v.begin(); > root [6] { while (b != v.end()) { > end with '}'> if (*b) cout << ((TString*)(*b))->Data() << endl; b++; }} > s1 > s2 > s3 > > So, if there's anything that needs to provide STL support, it's CINT, > and Masa has been working damn hard on that. > > So far so good. We can use (most of) the STL class interactively, but > what about I/O? Well, the ROOT I/O system relies on inheritance from > TObject, so that rules out STL classes immediately, since we can not, > with out break STL, make for example vector<class,class> subclass > TObject; it wouldn't be STL if you did. So what to do? Well, the > solution is to encapsualte the STL classes in subclasses of TObject, > like IntVector above. As far as I remember, all the frameworks that > provide persistent object store work like this, including G4, > Objectivity, and ClHEP based projects. > > So, the question "Why no, Rene?" is easy to answer: It's just not > possible! What can be done is make the parsers, lexers and code > generators understand templates. > > Above, I said > > What one can compile in (sometimes) are the specific instantations > of a template. > > The "(sometimes)" is a sutble point and has to do with how to make > sure there's exactly one instance of a template instantition. There > are two models: The Borland model and the Cfront model. More on these > models can be found in the GCC info pages -> "Extensions to the C++ > Language" -> "Template Instantiation". > > Now, as for the matter of reallocation, why don't you just use a > TArrayD or something? That'll give you that as far as I remember. > Otherwise, implement a class, possibly a template, that has the method > Realloc that does the reallocation for you (see also > TStorage::Realloc). > > Yours, > > Christian Holm Christensen ------------------------------------------- > Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 > DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 > Denmark Office: (+45) 353 25 305 > Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:38 MET