Hallo Rene, On Wed, Dec 05, 2001 at 05:01:03PM +0000, Rene Brun wrote: > > When I run in non-split mode, the Streamer method of a class > > is processed. In split mode this function is never called, because > > all data memebers are branches themselves. Therefore, when I have > > to do some initialisation in the Streamer method of an own class, > > I should never enable splitting for this class. > > See Users Guide page 225. > You can instruct Root to not split a data member of a class > by specifying the two caharcters "||" in the comment field. You are right, of course, but I think it would be a good idea to have the option to disable splitting for a given class generally. When I write some class and if this class needs a custom streamer, which does some initialisation necessary to use the data, I have to tell everyone: Do not use splitting. There are cases, where splitting is forbidden for a class in general and if I could set a switch already in the class definition, this would be much easier for everyone. [...] > The difference is the time. It will take more time to process the non-split > branch. That's only true if the data members in a branch are used by their own. If the data memebers are used together most of the time, this should make no difference. And if I have to write a custom streamer, the latter is most probable, I think. > Concerning the browser, you are correct. It is possible to browse a non-split > object in principle. However, if we implement this feature, we will get > immediatly complaints that by double clicking on a data member, it takes time > to process the query. On the other hand this could be one way to illustrate > the advantages of the split mode ::) These advantages are quite clear, but what does the advantages help if I cannot use the split mode. Ok, you could argue, that I should avoid custom streamers at all, but consider the following example: We are going to convert our native DAQ data format into tree format. For some detectors types we have to handle arrays of integers with sizes changing from event to event or even with sizes, which are not known at initialisation time of the array. We started to use TArray, but whenever the size changes, the array is reallocated. In addition, chosing a large size does not help, too, because the whole array is written to disk. We now use a array class, which does only increase the size, but never reduce it. Only the used length is written to disk. To do the proper initialisation of array length and used length, a custom streamer is unavoidable. To gain from that, we have to use the class as a non-pointer, non-split data object. Maybe one can think of some additional automatic function generated by by rootcint/ClassDef/ClassImp. Whenever a branch connected to an class object is completely read via the GetEntry() call (because only then an instance of the whole object really exists), this specific function is called. This would disentangle the initialisation things from the real streamer purposes and one could gain from splitting even in these cases. Best regards, Volker -- Dr. Volker Hejny Tel: 02461/616853 ** Institut f. Kernphysik Fax: 02461/613930 ** ---------------------------------------------------------------- ** ** --- Forschungszentrum Juelich GmbH, D-52425 Juelich **
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:11 MET