> Hi Valery, > > You are absolutely right. Bare double pointers are faster. Actually I doubt it, since that's all a TArrayD IS (it has one data member -- a Double_t *), and none of the commonly used operators would be virtual, and I am assuming that Eddy is passing a TArrayD &, not a TArrayD (which would require copying); in that case the size of the thing passed is identical so THAT's not an issue. Both TArrayD::At() and operator[] are defined inline. The only place that there could be an efficiency issue is that ROOT puts bounds checking in both At and operator[], so there is no place to turn this off once you know that you are within bounds... If you wanted to avoid that (extremely small) inefficiency, I would argue that you should use std::vector<Double_t> & to pass your info, which would get you the best of all worlds -- bounds checking is available when you need it through the at() member function, and avoidable when you don't want it by using operator[], you can get the length of the vector with a size() call. Not only that, if you wanted to get ambitious you can use the STL's standard algorithms on the vector. I note that the C++ standard was VERY careful to make sure that objects inherently and the STL classes in particular pay *no* additional overheads over raw pointers. That using C++ OO's mechanisms makes you pay inherent performance penalties is a persistent myth which is just that, a myth. There are things you can do with those mechanisms that do impose penalties (e.g. virtual functions, virtual inheritance), but in well-designed structures these penalties are only paid when they would be necessary anyway (to implement run-time polymorphism, for example), and those things do not apply here. > Reason for using > currently TArrayD is the boundary checking !!, useful for testing > the code. "GetSize()" is only used four times, so change to "Double_t *" should > be painless. And this is going to continue to be true, for anyone who later wants to extend or modify's Eddy's classes. For this reason I would argue against going back to raw pointers. George Heintzelman gah@bnl.gov
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:38 MET