I agree completely with the observation about efficiency. It's a shame
about operator[] vs. operator(). Especially since STL expects subscripting
to be spelled [], which leaves us with a choice between being inconsistent
with STL or being inconsistent between single- and multi-dimensional arrays.
> > Another operator or a member function might be defined to accept
> > one based indices and to return a reference to a particular element.
>
> Okay, in this model you suggest:
> 1) operator[] plus proxies implement 0 based indexing
> 2) operator() implements 1 based indexing
> ???
>
> So 1) is familiar to C programmers, and 2) is familiar to Fortran
> programmers. That's cute, but has flaws:
> A) How do you represent arrays with specified bounds? The
> Fortran syntax dimension A(-4:4,-10:10).
You can always make the bounds arguments to the constructor. Of course,
if you want both (1) and (2), one or the other will have to be significantly
less efficient, at least for multi-dimensional arrays.
> B) Makes for lots of extra work for the container author.
But we thrive on long hours and hard work. ;-)
>
> I'd much rather see:
> 1) operator() emerge as the prefered indexing technique, at
> least for dense matrices.
> 2) Algorithms templated on client container type
> 2) Algorithm's use traits (or at least documented constraints)
> to discern array bounds.
(1) is the only reasonable spelling for multidimensional subscripting. Perhaps
it's the only spelling needed, if you permit a 1-D array to return a pointer
to the underlying representation, since you can [] the pointer all you like.
(2), version 1.0, is obviously worth pursuing. (I should mention at this
point, since no one else seems to have done so, that this still requires some
standard names in the matrix class interfaces. We never entirely get
away from standardizing classes.)
(2), version 1.1, is an interesting idea I'd like to see you amplify a bit.
Does this imply static bounds?
>
> --
> Geoffrey Furnish email: furnish@lanl.gov
> LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
>
> "Software complexity is an artifact of implementation." -Dan Quinlan
>