Would you care to elaborate?
Of course this is just my opinion. I think the GSL group is doing
a great service and since the code is GPL I should really be rolling
up my sleeves and coding instead of complaining.
When the first example program in their documentation defines 'int
main(void) { ... }' you have to wonder a bit. Why the 'void'? It
is perfectly legal, just odd looking and unnecessary. When I was
evaluating this for use in a production library at a large Equity
Derivatives firm a couple of years ago, I kept finding 'odd' things.
Ultimately I chose a Fortran library because GSL was not sufficiently
mature at that time. It has definitely come a long way since then.
If you belive a modern library should be written in C instead of C++,
you can stop reading now. Many of my qualms are due to issues relating
to the gyrations GSL goes to because it does not use C++. I've taken
flak over the years for insisting on writing certain libraries in C (and
even more flak for using Fortran) but I have come to the conclusion that
the small audience that insists on C is, well, small. I'm open to data
indicating otherwise.
Error Handling
I'm not a fan of the 'int status = gsl_function(...); if (status)
{...' method of error handling for functions that return doubles.
I am especially not a fan of having default error handlers call
abort(), like the assert macro in C. Of course I've had the head
of IT tear me a new asshole when a programmer of mine left an assert
in production code that got called 15 minutes before market open,
so I can't claim to be unbiased.
GSL does have 'natural form' calling conventions available (more
code on their side to maintain) but they do not permit error
checking. I prefer returning NaN's that have embedded error
information. If you don't check the return codes, at least your
program is more likely to return gibberish than to crash.
Vector and Matrix Routines
They do a fine job, but I would love to see something more along
the lines of
http://okmij.org/ftp/LinAlg.README.txt. I've tried out
every vector/matix library on the planet, I think, from BLAS and LAPACK
to the compiler busting Blitz++. Simple C++ wrappers for the former seem
to be the best solution for my needs.
General Comments
Excessive use of C macros in source code. Makes the code hard to
understand/fix/maintain.
Not modular. Dependencies between modules should be explicit.
At any rate, that's my 2 cents. Feel free to disagree, it's an internet
newsgroup after all. Comments are welcome.
