[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-gsl] (no subject)
From: |
Lars Schouw |
Subject: |
[Help-gsl] (no subject) |
Date: |
Thu, 12 Jan 2006 15:41:33 -0800 (PST) |
Andrew did you have to finish of you C++ template soluition for GSL?
Lars
Hello!
I posted about this once...mentioning a template
solution for sending a member function pointer. This
is my favorite solution and I have implemented a
version of this in an object-oriented library based on
GSL. I was actually planning on releasing it soon.
I should note that SEAL's mathlibs:
http://seal.web.cern.ch/seal/MathLibs/MathCore-1_0_0/html/index.html
has an alternative solution. Functions are specified
as classes which overload operator(). I have two
problems with this: 1) you can't easily have two
functions to be solved in the same class (how does it
know which operator() to call?), 2) you can't specify
parameters which are not class variables. (I could be
wrong about this...please let me know if I am...I
haven't had time to look at it too much.)
Anyway, I have been delayed releasing my library
(in addition to the problem of the US government
paperwork) because I discovered another thorny issue
(thread-safety) which I'd like to fix first. If a
"solver" class is a static member of a separate
user-created class, then the memory for the solver
must be separate from the solver class (as in GSL) so
that multiple instances of the user-defined class do
not clash. I'd love to hear ideas about this, and I'll
probably post a schematic solution soon.
HTH,
Andrew Steiner
---------------------------------
Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Help-gsl] (no subject),
Lars Schouw <=