This is the mail archive of the gsl-discuss@sourceware.cygnus.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: "Object oriented" description of functions



In principal I agree. That should be reasonable. The problem is that
there is no consistent object model throughout the GSL code. It's
getting to be a hodge-podge collection of foo.

Begin Rant:

I would like to see changes like this made uniformly throughout the
code.
On the other hand, I really don't give a shit. Stealing a phrase
from one of my favorite books, trying to build object-oriented
software in C is like trying to build a bookshelf out of mashed
potatoes.

My observation is that every C programmer has their own way to
do this sort of thing, they are all slightly different, and
the work required to fill in all the holes in an implementation
is tedious. That's what C++ compilers were invented for. Why
should I write code that can be automatically generated?

If somebody who wants to advocate some object model for C code
like this wants to step forward, by all means please do. But
it should be type-safe, efficient, resilient to changes, 
in particular supporting some notion of binary-compatibility,
and anything else I might think of later.

If you tell me "look at GTK", I did already. Now what?

End of rant.

-- 
G. Jungman


Fabrice Rossi wrote:
> 
> In several places, we have "normal" functions (for instance gsl_function), as
> well as differentiable function (gsl_function_fdf). Unfortunately, it's not
> currently possible to simply view a differentiable function as a normal
> function. This can be done for instance by replacing the current definition of
> gsl_function_fdf_struct by:
> struct gsl_function_fdf_struct
> {
>   gsl_function *f;
>   double (* df) (double x, void * params);
>   void (* fdf) (double x, void * params, double * f, double * df);
>   void * params;
> };
> 
> Evaluation macros need to be rewritten and we can add:
> #define GSL_FUNCTION(FDF) ((FDF)->f)
> to allow "casting".
> 
> I know this introduces an additionnal pointer, but I think it might be a good
> idea.
> 
> Fabrice Rossi

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]