Custom objects in TTrees

Hello,

This is a question about what trouble I might run in to with the following method of working, I am at the start of a project and so would rather ensure I have a robust way of working before running in to problems later…

I am looking at storing custom class objects in TTrees. I have been defining my own C++ class, which has various member properties (either simple types like int, float etc, vectors of them, or more custom class objects, or even some root objects like histograms), getters and setters for these properties, and some handy functions etc. To allow me to use CINT or PyROOT, I am generating a reflex library for my custom classes. So I generate a file containing a TTree with a branch of my custom class type, and I have figured out how to retrieve the object from the branch and everything seems to be working great. I even like how the TTree seems to be able to directly see the members of the custom objects, thanks for branch splitting, so I can do TTree selections with those properties easily.

OK, so what I am worried about is if I am going to run in to problems when I try changing the code of my custom class. If I have already generated a TTree of objects with the old “definition” of my class, at what point would these objects become useless? With a bit of playing around I have noticed that if I am adding some new properties and functions to my class, I still seem to be able to work with the files made with the old class code - ROOT doesn’t fall over, it just leaves those properties as their default value. But I do also recall that when I played around with some class code in a previous project, I do recall that my code seg-faulted and made those files containing the old class objects useless.

So, what can I get away with changing about my class, and what will cause me to be unable to read and work with the old objects? How does this apply to CINT and compiled code? So far, my class is just a basic C++ class, but I see that the “Adding a class” chapter of the user guide suggests including the “ClassDef” and “ClassImp” macros - should I really try incorporating these in to my class? I recall having had some compiling problems when trying to add these to my code and get them in to my reflex library. What benefit do these macros really provide? I see there’s a “ClassVersionID” property in these macros, will changing that number make objects of an older “version” of the class useless, or how will ROOT handle these?

Sorry if this question is a bit open-ended, in summary I am looking to know what things I should be aware of when storing objects in TTrees and then potentially making changes to the class code for that object.

Cheers!
Will

[quote]But I do also recall that when I played around with some class code in a previous project, I do recall that my code seg-faulted and made those files containing the old class objects useless.[/quote]This is unexpected behavior. You should always be able to read the file containing ‘older’ data if you are not using any custom streamer.

[quote]including the “ClassDef” and “ClassImp” macros - should I really try incorporating these in to my class? I recall having had some compiling problems when trying to add these to my code and get them in to my reflex library.[/quote]genreflex only recently added proper support for classes using ClassDef.

ClassDef improve performance by reducing the file system a little bit (without the ClassDef we need to store an addition checksum for each object) and by making type lookup faster. It also makes customizing the schema evolution much easier by giving a specific ‘number’ to each class schema.

[quote]will changing that number make objects of an older “version” of the class useless
[/quote]No, they will still be readable.

Cheers,
Philippe.