Re: Re: Bug or feature?

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Wed, 28 Jan 2009 17:33:31 -0600


Hi Art,

Not just "presumably", GetObject works for all types (that you can store in a TFile) and
will handle all type of 'casting', including multiple inheritance. GetObject use templates
and GetObjectUnchecked to accomplish this.

So I _strongly_ recommend using

    mytype *myvar; A->GetObject("objname",myvar);

whenever retrieving an object from a TFile or TDirectory.

Cheers,
Philippe.

Arthur E. Snyder wrote:
> Ok I guess GetObject would be better .. it presumable works regardless
> of object's type
>
>
>
> A.E. Snyder, Group EC \!c*p?/
> SLAC Mail Stop #95 ((. .))
> Box 4349 |
> Stanford, Ca, USA, 94309 '\|/`
> e-mail:snyder_at_slac.stanford.edu o
> phone:650-926-2701 _
> http://www.slac.stanford.edu/~snyder BaBar
> FAX:650-926-2657 Collaboration
>
>
>
> On Wed, 28 Jan 2009, Philippe Canal wrote:
>
>>
>>> which is ok I guess, but I don't need to do that for histograms and the
>> need for casting is a bad interface.
>>
>> GetObjectUnchecked is a low level interface, don't use it directly :)
>> (... well unless you need to the 'Unchecked' behavior).
>>
>> Instead use:
>>
>> TF1 *sigmaPar; A->GetObject("sigmaPar",sigmaPar);
>>
>> sigmaPar will be zero if the object does not exist or is of the wrong
>> type.
>>
>> Cheers,
>> Philippe.
>>
>> Arthur E. Snyder wrote:
>>> I find I can recover my funtcions by being very explicit:
>>>
>>> root [16] ((TF1*)A->GetObjectUnchecked("sigmaPar"))->Print()
>>> sigmaPar : pol4 Ndim= 1, Npar= 5, Noper= 1
>>> fExpr[0] = pol4 action = 130 action param = 401
>>> Optimized expression
>>> fExpr[0] = pol4 action = 130 action param = 401
>>> Par 0 #alpha_{0} = 0.00493591
>>> Par 1 #alpha_{1} = 0.0171368
>>> Par 2 #alpha_{2} = -0.00493408
>>> Par 3 #alpha_{3} = 0.00143038
>>> Par 4 #alpha_{4} = -0.000135192
>>> root [17] ((TF1*)B->GetObjectUnchecked("sigmaPar"))->Print()
>>> sigmaPar : pol4 Ndim= 1, Npar= 5, Noper= 1
>>> fExpr[0] = pol4 action = 130 action param = 401
>>> Optimized expression
>>> fExpr[0] = pol4 action = 130 action param = 401
>>> Par 0 #alpha_{0} = 0.00493591
>>> Par 1 #alpha_{1} = 0.0205642
>>> Par 2 #alpha_{2} = -0.00493408
>>> Par 3 #alpha_{3} = 0.00143038
>>> Par 4 #alpha_{4} = -0.000135192
>>>
>>> which is ok I guess, but I don't need to do that for histograms and
>>> the need for casting is a bad interface.
>>>
>>> -Art S.
>>>
>>>
>>> A.E. Snyder, Group EC \!c*p?/
>>> SLAC Mail Stop #95 ((. .))
>>> Box 4349 |
>>> Stanford, Ca, USA, 94309 '\|/`
>>> e-mail:snyder_at_slac.stanford.edu o
>>> phone:650-926-2701 _
>>> http://www.slac.stanford.edu/~snyder BaBar
>>> FAX:650-926-2657 Collaboration
>>>
>>>
>>>
>>> On Wed, 28 Jan 2009, Arthur E. Snyder wrote:
>>>
>>>>
>>>> Hello RootWorld:
>>>>
>>>> I'm having an odd problem saving TF1's in files. I have two
>>>> versions of the same function with the same name. I save them in
>>>> two different files, call them A and B. The functions differ only
>>>> in the values assigned the parameters.
>>>>
>>>> If I open file A, look at it (Draw or Print), then file B, I get
>>>> the function with the A-parameters. If I open in the other order I
>>>> get the B-paramters. If I cd to one of them, I still get function
>>>> with the parameters of the file 1st openned.
>>>>
>>>> This is completely unlike the behavoir of n-tuples or histograms
>>>> where if I open multiple files I get the one I'm currently cd into.
>>>> I use this all the time to track, e.g., what histogram I want to
>>>> fit at a given time.
>>>>
>>>> But TF1's don't behave the same way even though they all inherit
>>>> from TObject and should I think behave the same way.
>>>>
>>>> Is this a bug or a feature? Is this a well known problem?
>>>>
>>>> I can certainly kuldge my way around it -- by assign some differing
>>>> names that I'll have to keep track of, but it does add another
>>>> layer of possibley buggy bookkeeping that I thought root was doing
>>>> for me.
>>>>
>>>> -Art S
>>>>
>>>> Example:
>>>>
>>>> A as parameter 1 = 0.0171368; B has par1=0.0205642
>>>>
>>>> root [0] A=new TFile("Res_funsT.root")
>>>> (class TFile*)0x8db4540
>>>> root [1] .ls
>>>> TFile** Res_funsT.root
>>>> TFile* Res_funsT.root
>>>> KEY: TF1 sigmaPar;1 pol4
>>>> KEY: TF1 apar;1 pol0
>>>> KEY: TF1 npar;1 pol0
>>>> KEY: TF1 mupar;1 pol3
>>>> KEY: TF1 power;1
>>>> [0]*([3]*TMath::Gaus(x,[1],[2],1)+(1.0-[3])*TMath::Gaus(x,[4],[5],1))
>>>> KEY: TF1 pnorm;1
>>>> [0]*(1-TMath::Exp(-[1]*x))*(1-TMath::Exp(-[1]*x))
>>>> root [2] sigmaPar->Print()
>>>> sigmaPar : pol4 Ndim= 1, Npar= 5, Noper= 1
>>>> fExpr[0] = pol4 action = 130 action param = 401
>>>> Optimized expression
>>>> fExpr[0] = pol4 action = 130 action param = 401
>>>> Par 0 #alpha_{0} = 0.00493591
>>>> Par 1 #alpha_{1} = 0.0171368
>>>> Par 2 #alpha_{2} = -0.00493408
>>>> Par 3 #alpha_{3} = 0.00143038
>>>> Par 4 #alpha_{4} = -0.000135192
>>>> root [3] B=new TFile("testTF1.root")
>>>> (class TFile*)0x8df5f58
>>>> root [4] B->cd()
>>>> (Bool_t)1
>>>> root [5] sigmaPar->Print()
>>>> sigmaPar : pol4 Ndim= 1, Npar= 5, Noper= 1
>>>> fExpr[0] = pol4 action = 130 action param = 401
>>>> Optimized expression
>>>> fExpr[0] = pol4 action = 130 action param = 401
>>>> Par 0 #alpha_{0} = 0.00493591
>>>> Par 1 #alpha_{1} = 0.0171368
>>>> Par 2 #alpha_{2} = -0.00493408
>>>> Par 3 #alpha_{3} = 0.00143038
>>>> Par 4 #alpha_{4} = -0.000135192
>>>>
>>>> --actually it seems to be more a question of which version of
>>>> function I look at 1st; if open A, don't look at it, then open B,
>>>> I'll get B values, but A->cd() will not get me the A values.
>>>>
>>>>
>>>>
>>>> A.E. Snyder, Group EC \!c*p?/
>>>> SLAC Mail Stop #95 ((. .))
>>>> Box 4349 |
>>>> Stanford, Ca, USA, 94309 '\|/`
>>>> e-mail:snyder_at_slac.stanford.edu o
>>>> phone:650-926-2701 _
>>>> http://www.slac.stanford.edu/~snyder BaBar
>>>> FAX:650-926-2657 Collaboration
>>>>
>>>>
>>>>
>>>> On Wed, 4 Apr 2007, Philippe Canal wrote:
>>>>
>>>>> Hi Arthur,
>>>>>
>>>>> I can not reproduce the problem (or do not understand your
>>>>> description :) ).
>>>>>
>>>>> Can you send me a complete running example (and the output as you
>>>>> see it)
>>>>> as well as the version of ROOT where it fails for you).
>>>>>
>>>>> Cheers,
>>>>> Philippe.
>>>>>
>>>>> -----Original Message-----
>>>>> From: owner-roottalk_at_pcroot.cern.ch
>>>>> [mailto:owner-roottalk_at_pcroot.cern.ch]
>>>>> On Behalf Of Arthur E. Snyder
>>>>> Sent: Monday, April 02, 2007 4:43 PM
>>>>> To: Rene Brun
>>>>> Cc: 'roottalk (Mailing list discussing all aspects of the ROOT
>>>>> system)'
>>>>> Subject: [ROOT] TString bug (or feature)?
>>>>>
>>>>> Hi Rene et al.,
>>>>>
>>>>> I find that when I try to read the blank separated charachters in
>>>>> a line
>>>>> into TString from an istringstream it has a strange behavior. If
>>>>> the last
>>>>> character is followed directly by a line-feed it gets skipped.
>>>>> Apparently
>>>>> eof or something is set by reading it and the loop ends w.o.
>>>>> giving you a
>>>>> chance at the characters just read. The result is you lose the last
>>>>> character string. If I use std::string instead, it works as I
>>>>> expect it
>>>>> too.
>>>>>
>>>>> The code is as follows:
>>>>>
>>>>> #include "readCard.hh"
>>>>> #include <TString.h>
>>>>> #include <iostream>
>>>>> #include <vector>
>>>>> #include <string>
>>>>>
>>>>> using std::istream;
>>>>> using std::endl;
>>>>> using std::cout;
>>>>>
>>>>> //read strings till "eol" marker or natural end; if nread!=0 read
>>>>> nread
>>>>> string (no marker)
>>>>> Int_t readCard(istream& card,std::vector<TString>& list,Int_t
>>>>> nread) {
>>>>> Int_t count=0;
>>>>>
>>>>> TString temp;
>>>>> // std::string temp;
>>>>> while(card >> temp) {
>>>>>
>>>>> cout << "count:" << count << " temp:" << temp << endl;
>>>>>
>>>>> if(nread==0 && temp=="eol") break;
>>>>> if(nread==0 && temp=="*eol") break;
>>>>> if(nread==0 && temp=="!eol") break;
>>>>> count++;
>>>>>
>>>>> list.push_back(temp);
>>>>> if(count==nread) break;
>>>>>
>>>>> } // loop
>>>>>
>>>>> return count;
>>>>> }
>>>>>
>>>>> -Art S.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Thu Jan 29 2009 - 00:33:39 CET

This archive was generated by hypermail 2.2.0 : Thu Jan 29 2009 - 05:50:02 CET