Hi Vincent, You have made an excellent analysis of the situation and I am very happy if our views finally converge. As I said, TH2 and TH3 are candidates to be removed in a coming version without breaking backward compatibility. Rene Brun Vincent Colin de Verdiere wrote: > > Hi Rene and Rooters ! > > Some corrections about my previous message.... > > My comments on the inheritance tree were done a little too fast and I am > here trying to correct them and to explain why... > > The objective was to build histogram classes with SIMULTANEOUS > variations of the number of dimensions (1, 2 or 3) AND of the data > types (char, short, int, float, double). It was decided NOT to use > templates and it was also required to minimize code duplication. > > Code sharing between classes can be done, in c++, through class > derivations. Therefore, in the THxxx structure, it was logically decided > to use derivation for data types, i.e. to have one branch of inheritance > per data type. > This choice discards the other possible inheritance tree which would be > based of the number of dimensions. One branch for histogram 1D, one branch > for histogram 2D, ... . > Making this second choice is not possible because it implies a lot of code > duplication between histo1dfloat and histo3dfloat for example. > > It is not possible or dangerous (to my view) to use both > inheritance structures at the same time and that's why many methods can > only appear in the base class (TH1). For example, the method "TProfile > *TH1::ProfileX(...)", I quoted before, is specific to 2D histograms and > would, nicely, be placed in TH2. But this, in fact, cannot work > because this method uses other methods defined in the base class (TH1). > So, in this case, inheritance CANNOT be used to distinguish THxxx by their > number of dimensions. > > Finally, I will conclude that, to my understanding, classes TH2 and TH3 > could be removed without inconvenience and that, it would make the code > clearer to use and therefore easier. > > Besides, I agree with the idea of simplifying and modularising the code by > moving high level functions (fits...) out of the base classes. In > this view, Taxis inline functions (like TH1::GetBinCenter) only save > typing and could be removed too. > > -- Vincent
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:19 MET