Hi Volker,
The simple case that you describe does not require a custom Streamer.
You should try to banish as much as possible custom Streamers.
Assuming
class Myclass {
int fSize; //current size of array fData
int fN; //effective length of array fData (<= fSize)
int* fData; //[fN] my variable length array
Not only, you do not need a custom Streamer, but you can also use split mode.
When you write you data (in a Tree or not), you can call the Myclass
constructor, decide to create fData in the constructor or not. You can call
a function of Myclass to create fData with a length fN at any time.
If the array already exists and has fSize >= fN, you do not need to reallocate
a new array.
When reading, ROOT knows how to build the array again with the right size.
Rene Brun
When you set the arrayVolker Hejny wrote:
>
> 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