I’m having some trouble with the following: I’d like to save a map into a ROOT file (on its own) that would be the “moral equivalent” of the following STL map:
std::map< std::pair< int, int >, int >
I started experimenting with TMap. Since TMap needs both its key and its value type to be a TObject, I selected TObjArray as the key type (holding two RooInt objects) and RooInt as the value type. This at least seems to work, I can save the map into my output file without problems.
However I would like to read this objects from the file in python. This seems pretty much impossible at the moment. I had to realize that the RooInt class is quite unusable from Python. This class only defines a type conversion operator on the C++ side to allow access to the integer number that it wraps. But unfortunately this type conversion operator is not accessible from Python. Very unfortunate that there is no RooInt::Value() function for instance that would return the Int_t value of the object…
So since I’m stuck with the problem, I thought I would ask here: How should I save such a map in my output file in a way that would be readable both from C++ and from Python?
Indeed, that could be a brute force method. However I want to create a file that is readable by “vanilla ROOT”. So requiring the loading of an extra library is a no go for me.
But while we’re on the subject: If I save a few std::map-s into a TTree, how do I read them from Python? Can I even do that? I can read those maps back with a compiled C++ code without problems, but have no idea how to do it from Python. (I always get some sort of crash when I try to access this variable.)
By this rate I’m afraid that I’ll have to give up my plan of making this “file format” readable from PyROOT.
(I’m trying to save configuration information as meta-data in my files, that’s why I want to use various maps.)
I was about to put together an example code right now, but for some reason I couldn’t get it to crash anymore. Then I realized that last time I’ve been using the ROOT version set up by the ATLAS offline software, and now I’ve been experimenting with a standalone 5.22 ROOT release. So it seems that the std::map reading is working just fine in a vanilla ROOT.
I can actually confirm that my example code doesn’t work when I set up AtlasOffline-15.6.4,64,gcc43,opt. The python code actually gives a lot of runtime warnings about duplicate entries for map<string,int> etc. objects. I see these warnings when running athena jobs as well, but so far I considered them unimportant.
Since it’s turning into an ATLAS-specific discussion, I guess we should follow up on one of the HyperNews if you agree.
yes, sent an example script to any of the atlas offline help lists if you want. Just for the record here: there are typically multiple versions of standard maps available in an ATLAS setup, both from/for CINT and from Reflex (Relax). Things tend to go wrong if dictionaries are mixed, in particular it can happen that these get updated during the creation of the python class (spooky, but that did happen on occasion and has since been fixed, although it may not be in 5.22).