Hi, I am trying to use a class with bitfield members. The class inherits from a pure virtual but not TObject. The reason it to avoid the 8-byte TObject overhead (see the p.s). The 4-byte vtbl ptr is still there in both cases but I will assume that ROOT does not store it on disk for every object, right? (please confirm) When aclic is executed I get errors like the following
In member function virtual void namespace::classname::ShowMembers(TMemberInspector&)
filename_C_ACLiC_dict.cxx:415: error: attempt to take address of bit-field structure member ‘ROOT::Shadow::namespace::classname::bitfield_member
What is the way to make this work? Hopefully not writing my own streamer… cheers,
filimon
p.s. As a parallel discussion/solution, will setting the TObject::fBits and TObject::fUniqueID to 0 for all my objects in memory (let us say a few thousand of them in a TClonesArray) help at all with the subsequent compression in a TBasket and most importantly are there any side effects on changing these two dwords, assuming that I do not use them explicitly myself.
[quote] error: attempt to take address of bit-field structure member [/quote]ROOT I/O does not support bit-field at the moment, you will not be able to store a class containing one. I recommend take a look at the class TBits instead.
[quote]p.s. As a parallel discussion/solution, will setting the TObject::fBits and TObject::fUniqueID to 0 for all my objects in memory [/quote]I would not change those. They are either already initialized to zero or have a value set that is necessary for the good functioning of the infrastructure.
You can also skip their storing for you class by calling once before doing any I/O:TClass::GetClass("MyClass")->IgnoreTObjectStreamer();
Hi Phillipe, thanks, in fact I can get some good results by using Double32_t combined with bit range comments vs originally Double_t and I found out about this IgnoreTObjectStreamer() a little bit after sending the msg. Regarding this last one however there is a comment in the documentation about using it on the class that is directly derived from TObject. I do this on my Base: public TObject and having a look at my tree that contains TCloneArrays of Derived: public Base I see that the TObject fields are still there, although with a much higher compression that the other fields. 1. Is it normal that I still see the fields (they still occupy some space in the basket)? 2. Is the comment about the immediate derived class still valid? or 3. Should I try to IgnoreTObjectStreamer on the class I actually want to write maybe? Thanks,
filimon
p.s. About Double32_t, how does it work when 16 bit accuracy is requested? Does it pack data somehow? Quickly greping I see that is is a typefed double so I guess you have a custom-written streamer for it? Where should I look for this code?
Thanks, now it works! I suppose the comment about the directly derived class on root.cern.ch/root/html/TClass.ht … ctStreamer is now irrelevant then (fixed to handle arbitrary depth) or do I miss something?
Indeed the documentation is unclear. The recommendation is still needed when the object are streamed object-wise but is inaccurate for object streamed member-wise.
TObject::Write would store the object object-wise. If an object contains a collection (std::vector) of objects does object would be stored member-wise. If you use a TTree with split level grater than 0, the object would be split (See User’s Guide chapter on TTree for more details).
cheers,