Hi Volker, Volker Hejny wrote: > > Hi all, > > as far as I know, the basic situation concerning splitting and > streamers is the following: > > 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. > If this is correct, then, in principle, whenever I have the need > to define a custom streamer, splitting in general is a bad idea. > So, is there any way to disable splitting of a specific class > by default, e.g. in the LinkDef file, that the user does not need > to care about that? If not, I think that would be a good idea to > have that. > > The second question then is following: In accessing the data members, > e.g. in the Draw() command, the behaviour of split and non-split > branches are the same. The only difference I see is again the > behaviour when using the TBrowser. In principle it should be > possible to generate the branch structure taking the information > from TStreamerInfo. Are there any plans to do that? > The difference is the time. It will take more time to process the non-split branch. 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 ::) Rene Brun > 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