> > > The efficiency issue (TArrayD vs. Double_t *) will be resolved quickly later > > > this week by some profiling. I do remember from similar checks that > > > the difference was noticable, in particular the boundary checking. Anyhow, > > > I will try to get more quantitative. > > > I'd like to call your attention to > > http://root.cern.ch/root/htmldoc/TArrayD.html > > it says: > Data Members > public: > Double_t* fArray [fN] Array of fN doubles > > So there no problem with GetArray() etc, just use fArray "as is" > But then we may ask ourselve why we need TArrayD at this point > at all. The only explanation it is convinient otherwise one has to bother > about "new" / "delete" for all intermediate arrays. You're quite right. But that's a very good reason on its own. Having objects do memory management for you is IMHO one of the strongest advantages of using C++ at all, and while ROOT is less than perfect in making this work right, where the tools are available you should use them. I missed the public because I assumed that there were no such things as public data members, which of course is the usual in most C++ object frameworks (except for things which really are raw structs, like (e.g.) the STL pair<> template). I don't like having it public. It makes it too easy for someone to say: TArrayD x; x.fArray = <something> which the TArrayD will then delete (possibly erroneously) later. Especially if what you meant to write was *x.fArray = *something. At least having the GetArray, and Adopt and Set members makes it harder to make this kind of mistake than public data members do, though they still effectively expose the implementation. George Heintzelman gah@bnl.gov
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:39 MET