Automatic schema evolution for foreign classes

Hi,
I work on GLAST and we are considering a move to ROOT v4.08. We have noticed the update concerning schema evolution for foreign classes and are intrigued. Before going too far down this path - we would like to be certain to understand any pitfalls.

We use Gaudi as our framework, and would clearly like to use the same classes in a persistent form as we use on Gaudi transient data store.

Our current set of output classes, are strictly native ROOT. We make use of TClonesArray, where possible, for speed… I cannot help wondering about I/O speed if we did make a move to a set of foreign classes. I could imagine we would use std::vector or std::map rather than TClonesArray.

We have avoided using some stl constructs such as std::map in our ROOT classes, due to some problems we have had in the past. I assume that there is full stl support now?

Are there any specific things we should watch out for as we consider migrating all of our existing ROOT data classes to be non-ROOT specific?

(One would be a loss of backwards compatibility with any data files we have already generated - but we may be at a point in our evolution where that is ok)

Surely there are tradeoff here and we should make sure we go into this with our eyes open.

Thanks,
Heather

Hi Heather,

The general performance and features of the I/O have not really changed since the presentations we made at the ROOT workshop.

[quote]We have avoided using some stl constructs such as std::map in our ROOT classes, due to some problems we have had in the past. I assume that there is full stl support now?
[/quote]
There should not be any problems with using std::map. However reading std::map without the original library has not been implemented yet.

I do not recommend that you retrofit existing code to remove the TObject part. There are not much gain in doing so (and more headache).

So unless you have a specific reason (performance, space) to retrofit, don’t do it (and if you do have a specific reason, let us know maybe it is fixeable).

Also note that the run-time speed optimization of the TClonesArray (avoid new/delete when possible) is not provided for std::vector, etc.

However, if you develop new classes/features, you should feel free to use STL containers, and foreign classes.

Cheers,
Philippe.