Hi Alberto, Thanks for giving this example with STL. It is exactly the typical example where you overwrite your program ! You do not know the initial vector size in STL. In your case, it may work because you return a small number of parameters. Think what may happen if you have more parameters than your vector allocation! As I said in my previous mail, a function accepting a STL vector as argument could be a solution, but then you inflate the interface. Rene Brun On Thu, 19 Sep 2002, Alberto Garcia Raboso wrote: > Hi Rene, > > The reason is that I use STL vectors in my program, so with «void > GetParameters(Double_t*)» I can do > vector<Double_t> ValParams; > pFitResult->GetParameters(ValParams.begin()); > while with «Double_t* GetParErrors() const» I have to do > vector<Double_t> ErrParams; > Double_t *temp = pFitResult->GetParErrors(); > ErrParams.insert(ErrParams.begin(), temp, temp + NParams); > Only a matter of convenience, but, as you can see, it allows the > programmer to use arrays and STL vectors (and perhaps TVector, I've not > dealt with them). > > Cheers, > > Alberto > > Rene Brun wrote: > > > > Hi Alberto, > > > > I am a bit relunctant to implement this kind of interface in > > more classes (I know that it is in TFormula and some other classes). > > Passing a non const pointer as argument makes debugging more > > difficult in case, for example, the user provided array > > is not large enough. > > A solution where the array is created internally by the Get function > > is not a solution either because it confuses who is owning what. > > One could imagine more sophisticated solutions where a high level > > object, like TVector, STL vector is filled, but this is the door open > > to an infinity of prototypes in a class with the result that > > the interface looks more complex. > > > > At least, this is my view. May be a majority thinks differently. > > In this particular example with GetParErrors, why is the > > existing prototype not sufficient? Do you want to change > > the errors ? > > > > Rene Brun > > > > On Wed, 18 Sep 2002, Alberto Garcia Raboso wrote: > > > > > Hi ROOTers, > > > > > > In TFormula, the method GetParameters() is overloaded as > > > virtual Double_t* GetParameters() const > > > virtual void GetParameters(Double_t* params) > > > However, the method TF1::GetParErrors() has only one form > > > virtual Double_t* GetParErrors() const > > > > > > I find particularly useful the second prototype of GetParameters(), but > > > it doesn't exist for GetParErrors()... Is it intended or just an > > > oversight? > > > > > > Cheers, > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Alberto Garcia Raboso > > > CERN / EP > > > CH-1211 Geneva 23, Switzerland > > > Office 40-2B-19 (+41 22 76 71626) > > > E-Mail: Alberto.Garcia.Raboso@cern.ch > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Well, farewell, my hobbits! You should come safe to your own > > > homes now, and I shall not be kept awake for fear of your > > > peril. We will send word when we may, and some of us may yet > > > meet at times; but I fear that we shall not all be gathered > > > together ever again. > > > > > > The return of the King. J.R.R. Tolkien > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Alberto Garcia Raboso > CERN / EP > CH-1211 Geneva 23, Switzerland > Office 40-2B-19 (+41 22 76 71626) > E-Mail: Alberto.Garcia.Raboso@cern.ch > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Well, farewell, my hobbits! You should come safe to your own > homes now, and I shall not be kept awake for fear of your > peril. We will send word when we may, and some of us may yet > meet at times; but I fear that we shall not all be gathered > together ever again. > > The return of the King. J.R.R. Tolkien > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:10 MET