I have set up an analysis package where people frequently add to the set of classes for which we want to write dictionaries. Rather than have multiple people edit the LinkDef.h file directly, I have set up my Makefile to grep through the header files for the ClassDef phrase, then make use of the defined_in directive via
@$(foreach d,$^,echo "#pragma link C++ defined_in \"$(d)\";" >>$@;)
This works great for the classes themselves, but there is a problem. Many of the high-level classes have STL containers of other classes as members. Other member functions that interact with these containers work fine, but if the container itself is exposed, I can’t interact with them via the interpreter. Rootcint is not generating the dictionaries for these classes, even though I have the “link C++ nestedclasses” directive as well.
I’ve made a simple example to test the problem: a class MyClass, which contains a std::vector named “vec”. I compile with
rootcint -f Dict.cc -c `root-config --cflags` -p MySubClass.h MyClass.h LinkDef.h g++ -Wall -fPIC -shared -o libDict.so `root-config --libs --cflags` Dict.cc
root  .L libDict.so root  MyClass mc root  mc.vec.size() Error: Can't call vector<MySubClass,allocator<MySubClass> >::size() in current scope (tmpfile):1: Possible candidates are... (in vector<MySubClass,allocator<MySubClass> >) Error: Symbol mc is not defined in current scope (tmpfile):1: Error: Failed to evaluate mc.vec Error: Failed to evaluate mc.vec.size() *** Interpreter error recovered ***
Everything works fine if I add an explicit “#pragma link C++ class std::vector+;” to the LinkDef.h file, but this defeats my automagic building.
So, is this a bug? Or is this the intended behavior of the defined_in directive? If so, the description at http://root.cern.ch/drupal/content/selecting-dictionary-entries-linkdefh should perhaps be updated to be more explicit. If this is intended behavior, any straightforward workarounds to the problem?