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