Dear Rene
Thank you for your fast reply as usual.
This morning I had the idea to try:
static TString opt = "separate";
and now everything works fine, and your answer gives me a
first explanation why I have to use static.
However, I am far away to understand this issue, I checked
a couple of C++ books and did not find any explanation :-(
As far as I understand you should usually avoid to declare
static variables in methods since they never go out of scope.
Since I have a lot of such cases I would need to declare
a lot of variables to be static.
Do you think that this problem arises since I have defined:
static XNormationManager * sNormManager;
i.e. would this problem still exist if I simply declare:
XNormationManager * fNormManager;
Best regards
Christian
Rene Brun wrote:
> Hi Christian,
>
> It looks like you are just hitting a simple C++ scoping problem.
> In case you store a pointer to the second argument of your
> InitSelector function, this pointer will point to a dead area when
> the original TString object will go out of scope.
>
> Rene Brun
>
> On Sat,
> 20
> Dec 2003, cstrato wrote:
>
>
>>Dear Rooters
>>
>>Meanwhile, I could narrow down the error to the following
>>method in my GUI class XNormationFrame:
>>Int_t XNormationFrame::InitSelector()
>>{
>> Int_t err = 0;
>> TString opt = "separate";
>> err = XMainFrame::sNormManager->InitSelector("rank", opt.Data());
>> return err;
>>}
>>In this case I get the error described earlier.
>>
>>However, the following simple change DOES work:
>>Int_t XNormationFrame::InitSelector()
>>{
>> Int_t err = 0;
>> err = XMainFrame::sNormManager->InitSelector("rank", "separate");
>> return err;
>>}
>>
>>Can anybody explain me what could cause this error???
>>
>>Thank you in advance
>>Best regards
>>Christian
>>
>>
>>cstrato wrote:
>>
>>
>>>Dear Rooters
>>>
>>>I have the following strange problem and do not know how
>>>to find the error:
>>>
>>>I have a basic library and a couple of derived libraries,
>>>which define different XManager classes and subclasses.
>>>Using one of the derived libraries I am able to execute
>>>the following macro from within ROOT:
>>>
>>>void Normalize(
>>>{
>>> XNormationManager *manager = new XNormationManager("Manager");
>>>
>>> manager->Initialize("PixType");
>>> manager->InitSelector("rank", "separate", 4,0,0.3,400,0);
>>>// here I initialize XSelector::fOption = "separate"
>>>
>>> manager->New("test","~/ROOT/rootcode","PixType");
>>>// here I create file = new TFile(name,"CREATE", title)
>>>
>>> manager->OpenData("~/ROOT/rootdata/test.root");
>>>
>>> manager->Select("TestSet","tree1");
>>>// at this point XSelector::fOption is already set to:
>>>// fOption = "CREATE" instead of fOption = "separate"
>>>// when this code is part of a standalone GUI app!
>>>
>>> manager->Select("TestSet","tree2");
>>> manager->Select("TestSet","tree3");
>>>
>>> manager->Normalize("TestSet");
>>>
>>> delete manager;
>>>}
>>>
>>>Please note that this macro has always worked witout any
>>>problems and still runs perfectly fine.
>>>
>>>However, now I have developed a GUI application, where
>>>the user can set all parameters graphically, and where
>>>this code is implemented within different methods of
>>>my class XNormationFrame. In the XMainFrame I have defined:
>>> static XNormationManager *sNormManager;
>>>and the subframe calls e.g.
>>> XMainFrame::sNormManager->Initialize("PixType")
>>>etc.
>>>
>>>When I press the button to execute the same commands
>>>as in my macro, then XSelector::fOption, which is
>>>set to "separate" in InitSelector(), is strangley
>>>set to "CREATE" after execution of manager->New()!!
>>>
>>>I know that you cannot give me a concrete answer, but
>>>maybe you could tell me:
>>>Does this look like a buffer overflow?
>>>What are the usual errors which result in such an error?
>>>What can be done to track down this error?
>>>
>>>Thank you in advance
>>>Best regards
>>>Christian
>>>_._._._._._._._._._._._._._._._
>>>C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
>>>V.i.e.n.n.a A.u.s.t.r.i.a
>>>_._._._._._._._._._._._._._._._
>>>
>>>
>>>
>>>
>>
>
>
>
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:17 MET