Hi, I want to use the following construct in CINT prompt
namespace1::namespace2::classname::type where type is a public typedefed template class MyIdCollection as follows
My linkdef.h that builds the library has at the moment
#ifdefMAKECINT
#pragma link off all class; #pragma link off all function; #pragma link off all global; #pragma link off all typedef;
#pragma link C++ namespace namespace1::namespace2; #pragma link C++ nestedclass; #pragma link C++ nestedtypedef;
#pragma link C++ nestedtypedef namespace1::namespace2::classname::MyIdCollection;
but when I load it does not seem to recognize the type by tab completion or ctor eith wither typedef or nestedtypedef. What would be the correct syntax? Thanks,
filimon
You would need to use something like:[code]#ifdefMAKECINT #pragma link C++ nestedclass; #pragma link C++ nestedtypedef;
#pragma link C++ namespace namespace1::namespace2; #pragma link C++ class amespace1::namespace2::classname+; #pragma link C++ typedef namespace1::namespace2::classname::MyIdCollection; #pragma link C++ class std::set+; #endif[/code]
Well, I got a complaint about missing std::set (I assume you meant std and not set but I tried both). Anyway, this is now bypassed because the code is now refactored a lot, but I have another question. I try to write a tree, initialized after opening a file but I get this msg
Error in TROOT::WriteTObject: The current directory (Rint) is not associated with a file. The object (testsim) has not been written.
(testsim is the tree name). fFile cd() before the write function call does not seem to help. Any ideas on what could be wrong? Please note that this application loads a macro with gROOT->LoadMacro. Could this be related?
filimon
[quote]Well, I got a complaint about missing std::set (I assume you meant std and not set but I tried both)[/quote]Did you have a #include (yes I meant std::set ).
[quote](testsim is the tree name). fFile cd() before the write function call does not seem to help[/quote]Either the fFile is deleted or something else does a cd to TRint before you create the TTree object and/or you ought to replace tree->Write() with tree->GetCurrentFile()->Write().
Well, I have it somewhere, so it should be included also in linkdef.h then? I assumed this but as I said I stopped trying because I refactored the code and in fact got rid of a global which bothered me a lot By the way, the way that CINT handles templates and/or STL is a little obscure to me. Is there a public presentation or sth or does the ROOT doc include it everything that is to be known? (Haven’t looked there for years). cheers,
filimon
OK, now everything works perfectly in the application except a small problem. As I said I do a gROOT->LoadMacro(“file.C”) and subsequent gROOT->ProcessLine(“some_func_in_file.C”). I would like to have an output .root file. If I put it in the ctor of the main application that does the gROOT->ProcessLine calls (ie the TFile gets initialized before), when the ctor of the class that does everything (it is a singleton) finishes I end up in the root prompt (this is inteted so as to use the root prompt afterwards for calling member functions of the singleton) and then pressing .q brings out the dump at the end of the msg. If 1. I disable the TFile ctor or 2. move it (with a necessary change to free store allocation instead of the stack ie new TFile) or 3. I issue a delete gFile at the root prompt before .q I do not get this and root terminates properly. I suspect this is because somehow there is an involvement of the file associated with the macro loaded by gROOT->LoadMacro but do not know the internals. Any hint on this? cheers,
filimon
It is hard to tell what the problem is without seeing the actual code. One can probably track down the memory problem by running valgrind (and using root.exe). It is usually best to create the TFile object via new or even better via TFile::Open (which works for all types of access protocol instead of just local files).
Hi, yes indeed new TFile helped even when keeping the allocation in its original place, because the destructor is not automatically called at the end (singleton/global destructors call) .
).
By the way, the way that CINT handles templates and/or STL is a little obscure to me. Is there a public presentation or sth or does the ROOT doc include it everything that is to be known? (Haven’t looked there for years). cheers,