Re: problems using gsl routines in C++ objects

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

yes, it could. however in my case the situation is slightly more complicated
since some object parameters change during the execution. therefore
initialising them at instantiation is not applicable.

I thought of something like

class X
{
public:
 double p_1 , ... , p_n;  
...
private:
...
static gsl_function kernel ;

kernel.function = f ;
kernel.params  = (void*) this ;

gsl_integration_qagp( &kernel           , ... );         
}

static double f( double a , void *p )
{
    static X* x ;
       
    x  = (X*) p;

    return( a * ( x->p_1) * ... * (x->p_n) );
}

I'm not sure whether this will work or not. for the moment I'm using 
your former solution which
seems to be fine. :-)

>On Wed, 27 Feb 2002, Daniel Rohe wrote:
>
>I suppose that the following combines both ideas:
>
>#include <iostream>
>
>double apply( double (*func)(double , void *), double x, void* y )
>{
>  return func(x,y);
>}
>
>class X
>{
>public:
>  X(double aa) : a(aa) {};
>  static double f( double b, void* obj )
>  {
>    X* x = (X*) obj;
>    return b * x->a ;
>  }
>private:
>  double a;
>};
>
>int main()
>{
>  X x(4);
>  cout << apply( X::f, 2, (void*)&x ) << endl;
>  return 1;
>}
>
>
>>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
>>
>
>