Re: problems using gsl routines in C++ objects

[Fleur Kelpin <fleur at bio dot vu dot nl>]

Hi Daniel,

I don't know if this is one of the workarounds you were also thinking of,
but I solved a similar problem by writing an extra static member function
in X which has proper type. This function casts the object stored in void*
back to X* and then calls f in the object and returns the value:

#include <iostream>

double apply( double (*func)(double , void *), double x, void* y )
{
  return func(x,y);
}

class X
{
public:
  double f( double x ) {return 2*a; };
  int a;
  static double ff( double x, void* obj )
  {
    return ((X*)obj)->f(x);
  }
};

int main()
{
  X x;
  x.a = 4;
  cout << x.f(1) << endl;
  cout << apply( X::ff, 1, (void*)&x ) << endl;
  return 1;
}

You won't need the apply function, of course. It's just for testing.
Maybe there is a problem with extern "C" linkage and then you need to
declare ff outside of X.

If you should find a cleaner way, please let me know!

Greetings,
Fleur

On Tue, 26 Feb 2002, Daniel Rohe wrote:

> Hi there,
>
> I intend to pass a member function of an instance of some class X to a
> gsl integration routine, which
> requires a pointer of "double (*)(double , void *)" type. I have tried
> various things
> such as passing "this->function" or even explicitely casting "double
> (X::*)" to "double (*)",
> but I either get comilation errors or the compiler automatically
> converts "double (X::*)" to
> "double (*)". in that case when the function is called it is NOT the
> function belonging to
> the actual instance of X but rather a function "instantiated" without a
> parental object, thereby
> losing all information of the object's parameters.
>
> I do see certain workarounds for this problem but if anyone has a
> "clean" solution at hand
> I'd be grateful!
>
> cheers,
>
> daniel
>