Re: [ROOT] TGraph and vector

From: Rene Brun (Rene.Brun@cern.ch)
Date: Wed Jan 09 2002 - 12:38:26 MET


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