Re: [ROOT] writing fUniqueID and fBits

From: Suzanne Panacek (spanacek@fnal.gov)
Date: Thu May 03 2001 - 21:58:16 MEST


Hi Anton,
Rene just read over my response and pointed out that it is wrong!

You should not call obj->IgnoreTObjectStreamer but:

  MyClass::Class()->IgnoreTObjectStreamer

This sets a bit in the TClass object. Once this info is known to TClass,
there is no need to specify this at the object level.

There is no IgnoreTObjectStreamer in TObject.

My appologies,
Suzanne Panacek


----- Original Message -----
From: "Suzanne Panacek" <spanacek@fnal.gov>
To: "Anton" <anton.fokin@smartquant.com>
Cc: <roottalk@pcroot.cern.ch>
Sent: Thursday, May 03, 2001 1:39 PM
Subject: Re: [ROOT] writing fUniqueID and fBits


> Hi Anton,
> I am just adding a section on TObject to the Users Guide, including the
> answer to your question.
> To avoid streaming fBits and fUniqueID use:
>
> obj->IgnoreObjectStreamer();
>
> Since I am just adding a section on TObject to the users Guide I include
the
> paragraph that talks about fBits and fUniqueID
> Suzanne
>
>
> ------------ about fBits and fUniqueID-------------------
> A TObject descendent inherits two data members: fBits and fUniqueID.
> fBits:
> This eight-bit data member is to be used with a bit mask to get the status
> of the object. The kMustClean, kCanDelete, and kCanIgnoreStreamer (where
is
> this)  bits are in fBits. These can be set by any object and should not be
> reused.
> Bit 0 -13 are reserved, bit 14-23 can be used in different class
> hierarchies. Make sure there is no overlap in any given hierarchy. This is
> the description from TObject.h:
>
> enum EObjBits {
>    kCanDelete  = BIT(0),      // if object in a list can be deleted
>    kMustCleanup = BIT(3),     // if object destructor must call
>                               // RecursiveRemove()
>    kObjInCanvas = BIT(3),     // for backward compatibility only,
>                               // use kMustCleanup
>    kCannotPick  = BIT(6),     // if object in a pad cannot be picked
>    kInvalidObject  = BIT(13)  // if object ctor succeeded but
>                               // object should not be used
> };
>
> The TObject constructor initializes the fBits to zero depending if the
> object is created on the stack or allocated on the heap (why). Of the
status
> word the high 8 bits are reserved for system usage and the low 24 bits are
> user settable.
>
> fUniqueID:
> This data member can be used to give an object a uniqe identification
> number. It is initialized to zero by the TObject constructor and is
> basically a gift to the application. For example an Event Display may want
> to separate the graphics from its algorithm.
>
> These two data members are streamed out when writing an object to disk. If
> you do not use them you can save some space and time by specifying:
>
> obj->IgnoreObjectStreamer();
>
> If the file is compressed, the savings are minimal since most values are
> zero, however, it saves space when the file is not compressed.
> A call to IgnoreObjectStreamer also prevents the creation of two
additional
> branches when splitting the object. If left alone, two branches called
fBits
> and fUniqueID will appear and because you did not create them anyone
> browsing.
>
> ----- Original Message -----
> From: "Anton" <anton.fokin@smartquant.com>
> To: <roottalk@pcroot.cern.ch>
> Sent: Thursday, May 03, 2001 10:42 AM
> Subject: [ROOT] writing fUniqueID and fBits
>
>
> > Hi rooters,
> >
> > how can I avoid writing fUniqueID and fBits branches for any TObject
> > derived class? If I derive a class and write a custom streamer,
> > fUniqueID and fBits are still there.
> >
> > Regards,
> > Anton
> >
> >
>
>



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:44 MET