Hi,
On 12/04/2009 08:36 PM, Brian Gough wrote:
At Tue, 24 Nov 2009 17:54:46 -0700,
Gerard Jungman wrote:
Here are header files for a couple different approaches to containers.
I didn't bother with any implementations; it seems obvious how to
implement most of these functions.
The designs are not complete, but they express most of
the important stuff.
Thanks for the document, I have studied the designs this week. It
seems that changing to design 1 / 1u / 2 would be trading one set of
problems for another. Looking at each case, the change doesn't seem
sufficient to justify the compatibility cost.
Do you mean the compatibility to GSL 1 types by the compatibility cost?
When talking about GSL 2 I don't think we should give too much value to
maintaining backwards compatibility. GSL 1 is not going to cease to
exist, and people who have tied themselves deeply to GSL 1 data
structures can continue to use it.
3) Non-levelised types. These seem to be the price for type safety.
In terms of the look/feel, expressions like &row.vector and
&column.vector don't seem too unnatural to me.
Here is a crazy idea: If we take Gerards design 1, would it be too
absurd to use a horrible big wrapper struct like
typedef struct {
gsl_marray *m;
gsl_const_marray *cm;
gsl_marray_1 *m1;
gsl_const_marray_1 *cm1;
gsl_marray_2 *m2;
gsl_const_marray_2 *cm2;
gsl_marray_3 *m3;
gsl_const_marray_3 *cm3;
gsl_vector *vec;
gsl_const_vector *cvec;
gsl_matrix *mat;
gsl_const_matrix *cmat;
...
} gsl_container;
and make everything a gsl_container, and then always use them like
&a.mat or &b.vec? Maybe the const types could be in another
gsl_const_container struct..
One downside is that this would effectively mask the type of a or b in
program code (gsl_container a; // is it a vector, matrix, or marray?),
which might make reading code a pain..
--
[email protected]
http://iki.fi/tuomo.keskitalo
