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:37 MET