Optimal way to implement an attribute map

ROOT
1

I’d like to get opinions on the good ways to implement an attribute map that I can save to a ROOT file. Effectively I have a bunch of objects in my files, and I want to store alongside them a generic map of attributes of potentially arbitrary type, so I could use this to attach e.g. string or int attributes to any object in my file.

So one idea is try using a TMap, with key equal to the object, and value equal to a TList. Inside the TList I could utilise TParameter for numerical attributes, TNamed for string attributes.

My concern is perhaps this is inefficient? Lots of TObjects, I believe there are eventually limits on the number of TObjects you can have in a given process (16M?). Also the TList doesnt ensure each object it contains has a unique name …

Are there any other thoughts here? Remember I need to be able to save this attribute map to the file alongside the objects that it is providing attributes for.

Thanks!

2

There is no limit on the number of TObjects. (There used to be a limit on the number of TObjects that were referenced by a TRef but that has been lifted too a very long time ago).

The only limit you might encounter is the 1Gb limit for each I/O transaction/operation/TKey.

Cheers,
Philippe.

3

Ok thanks for the comment there Philippe.

I wanted to share some experience from experimenting over the past couple of days, because it still isn’t entirely clear what the best implementation is.

I started out with a TMap, with keys being the objects themselves and values being a TList of the attributes to associate to the object. Initially I found this limited me to the attribute names effectively being the same as the attributes themselves: I couldn’t attribute one object to two different objects under different attribute names. A hacky workaround was to use a TObjArray as a containing object, since I can name the TObjArray how I please, and the single element in the array is interpreted as the attribute value. I really wanted something like a TRef but I cannot give a TRef a name of my choosing. Have I missed an obvious existing class here?

This made me think then, should I just be using another TMap for the attributes, rather than a TList? I could then use TObjStrings as the keys here.

Are there some good pros and cons other using a TMap rather than a TList of the container type of my attributes?

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.