This is the mail archive of the
gsl-discuss@sourceware.cygnus.com
mailing list for the GSL project.
Re: "Object oriented" description of functions
- Subject: Re: "Object oriented" description of functions
- From: Gerard Jungman <jungman at lanl dot gov>
- Date: Fri, 10 Dec 1999 16:00:15 -0700
- CC: GSL discussion list <gsl-discuss at sourceware dot cygnus dot com>
- Organization: LANL T-8
- References: <384E72F9.E242FF57@ufrmd.dauphine.fr>
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