This is the mail archive of the
mailing list for the GSL project.
Re: gsl container designs
- From: Brian Gough <bjg at gnu dot org>
- To: Gerard Jungman <jungman at lanl dot gov>
- Cc: gsl-discuss at sourceware dot org
- Date: Fri, 04 Dec 2009 18:36:32 +0000
- Subject: Re: gsl container designs
- References: <firstname.lastname@example.org>
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.
Regarding the introductory points.
2a+b) While we may have had some kind of goal of supporting C++ I
don't think it's worth encouraging that today as the gap between the
languages has widened so much since the start of the project.
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.
4) I think this can be fixed in the current framework.
5) Since row-major was in the original design it's too much of a break
to change that.
I think the most realistic way forward is to add a multiarray type,
with rank-1, rank-2 and rank-N versions, in the existing framework and
use non-levelised types for const/non-const views to preserve