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 type-safety. -- Brian Gough
