Hi Jonathan,
Yes indeed you can use pointers to static member functions. But in doesn't
solve the problem I tried to point out. A static member function is still
a global function (only attached to a class, i.e. basically in a
namespace). And, as you say, you still need within the (global) function
to retrieve somehow on which object you want to apply it. So it's in
principle equivalent to a global function.
A function object is an object which can be used as a function,
i.e. it has a member function
XXX operator()(xxx);
My proposal is something like the following:
----
class TSomeObject {
...
public:
...
void fcn(Int_t&, Double_t*, Double_t&f, Double_t*, Int_t); // the member
of TSomeObject we really want to execute of a certain instance
// sub class
class TFCNForw {
private:
TSomeObject* fSomeObj; // pointer to some object
public:
TFCNForw(TSomeObject* obj):fSomeObj(obj);
void operator()(Int_t&, Double_t*, Double_t&f, Double_t*, Int_t);
}
}
void TSomeObject::TFCNForw::operator(Int_t&npar, Double_t*gin, Double_t&f,
Double_t*u, Int_t flag)
{
fSomeObj->fcn(npar, gin, f, u, flag);
}
-----
An instance of TSomeObject::TFCNForw is a function object. Instead of
using a global function, we now can use such an instance as the fcn
function. In order for this to work, the call to fcn (i.e. within
TMinuit) should be a template function. All this is not a new idea. STL
uses the same mechanism for it's algorithms. I'm quite convincent this
will also work for ROOT. The clear advantage is you don't have to 'go
out of scope of the object' anymore (which, I think, is a typical example
of none Object Oriented code), in practice you don't need to use
Set/GetObjectFit anymore.
Cheers, Rutger
On Wed, 2 Feb 2000, Jonathan M. Gilligan wrote:
> You are mostly correct, but for language lawyers, it's worth noting that
> you CAN call a pointer to a static member function without requiring an
> object. If the member function is not static, then it may refer to
> non-static member variables of the object, which is why it needs an object
> tell it where to find those variables. CINT does support pointers to member
> functions, because there is not a standard way that compilers construct the
> vtbl in the object (see the ARM), so there is not a portable way for the
> interpreter to deal with pointers to member functions of objects defined in
> compiled code.
>
> The following code does compile and run correctly under a compliant C++
> compiler, but will fail under CINT.
>
> #include <iostream>
>
> using namespace std;
>
> class bar
> {
> public:
> static int fcn(int i);
> };
>
> int bar::fcn(int i)
> {
> return i*i;
> }
>
> void foo()
> {
> int (*pfcn)(int i) = bar::fcn;
> cout << "fcn(2) = " << (*pfcn)(2) << endl;
> }
>
> void main()
> {
> foo();
> }
>
>
> At 12:06 PM 2/2/2000 , you wrote:
> >There is a more serious problem, which is partly a limitation by C++ (but
> >which can't be avoided). You can have pointers to member functions (see
> >B. Stroustrup par 15.5) but they have to be invoked on an object. So in
> >your case you have the pointer to member function:
> >
> >void (DPrecAlign::*)(int,double *,double,double *,int)
> >
> >You can even set a variable which is a pointer to this member function:
> >
> >void (DPrecAlign::*)(int,double *,double,double *,int) pntrToMem =
> >&DPrecAlign::fcn;
> >
> >but you have to use it on a DPrecAlign object, i.e.,
> >
> >DPrecAlign* tDPAObj = <something>;
> >(tDPAObj->*pntrToMem)(npar, gin, f, par, flag);
> >
> >
> >The syntax is horrible but this is what it boils down to. The upshot is
> >that a pointer to a member function is not the same thing as a pointer to
> >a normal function. This means you can not use it as a pointer to a member
> >function.
>
> ===========================================================================
> Jonathan M. Gilligan <jonathan.gilligan@vanderbilt.edu>
> Research Assistant Professor of Physics (615) 343-6252
> Dept. of Physics and Astronomy, Box 1807-B Fax: 343-7263
> 6823 Stevenson Center
> Vanderbilt University, Nashville, TN 37235 Dep't Office: 322-2828
>
>
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:18 MET