Re: problems using gsl routines in C++ objects

[Daniel Rohe <d dot rohe at fkf dot mpg dot de>]

ok, this is a possible solution. however I'm a little concerned about 
the performance loss.
the integration over this function will be one of the low lying 
routines, therefore an extra indirection
could lead to a substantial loss in performance.

the workaround I was thinking of consists of defining a "classless" 
static function and passing
all relevant object attributes via the parameters-interface. this 
however destroys in a way the C++
idea of "encapsulated data", but I guess at this point one has to make 
certain compromises.

anyway I'll try both solutions and see what happens.

thanks for the help!!

daniel 

>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
>>
>