tmb@ganymede.UUCP (09/04/88)
>From @rome.ics.uci.edu:schmidt@harlie.ics.uci.edu Sun Sep 4 01:20:24 1988 remote from ai-lab
From: "Douglas C. Schmidt" <ai-lab!schmidt%harlie.ics.uci.edu%paris.ics.uci.edu>
Section 1.13 of Stroustrup (pages 30-32) describe the development of a
vector type. On page 32 Stroustrup remarks ``It is quite simple to
provide multi-dimensional arrays, [etc].'' However, is it correct to
state that these multi-dimensional arrays require a functional syntax,
i.e., foo(i,j,k), rather than an extension of the ``operator[]''
concept to multiple dimensions, e.g., foo[i][j][k]? In other words,
in G++, at least, it does not seem possible to overload the []
notation for more than a single dimension. Is this a deliberate
decision based upon the C++ reference manual, a difficult
semantic/syntactic construct, or simply an unimplemented feature in
G++?
Let me quote from a recent paper:
"We would like to see multidimensional subscripting added to the
C++ language, i.e. to allow the programmer to overload {\tt
operator[]} with multiple arguments. This would require the
programmer to parenthesize expressions containing the ``,''
operator inside the subscripting operator, an incompatible but
minor change in the syntax of the language."
You could use functional syntax, but somehow that doesn't seem
appropriate. After all, all of this is a question of syntactic
sugar, and if you don't care about whether it's pretty, you
might as well write "ref(foo,i,j,k)" and forget about the operator
notation altogether.
Thomas.bs@alice.UUCP (Bjarne Stroustrup) (09/04/88)
Douglas C. Schmidt writes: > Section 1.13 of Stroustrup (pages 30-32) describe the development of a > vector type. On page 32 Stroustrup remarks ``It is quite simple to > provide multi-dimensional arrays, [etc].'' However, is it correct to > state that these multi-dimensional arrays require a functional syntax, > i.e., foo(i,j,k), rather than an extension of the ``operator[]'' > concept to multiple dimensions, e.g., foo[i][j][k]? In other words, > in G++, at least, it does not seem possible to overload the [] > notation for more than a single dimension. Is this a deliberate > decision based upon the C++ reference manual, a difficult > semantic/syntactic construct, or simply an unimplemented feature in > G++? First, GNU C++ does exactly what cfront does here and I think it is not only correct according to the manual but also the best thing to do. I think that an array with multiple dimentions, such as a Fortran a(1,2,3), or a C++ array accessed (through a dope-vector or something) using an overloaded operator(): a(1,2,3), is different in several ways from the C array you get by repeated use of subscripting v[1][2][3]. For example, there need not be a three dimentional array allocated for v[1][2][3] to make sense; arrays of pointers may enter into the picture somewhere. Think of argv. I therefore have no objections to the () notation here and since it was good enough for Fortran it is probably good enough for C++. On the other hand, overloading operator[] to take more than one ``sunbcript argument'' runs into a problem with C. a[1,2,3] is perfectly legal C and C++ (provided a is of a suitable type). Here ``a'' is subscripted by the comma expression (1,2,3) whose value is, of course, 3. Diddling the semantics of C++ so that a comma in a subscript of an overloaded operator[] comes to mean something different from a comma in other expression contexts does not seem sensible.
baud@gt-eedsp.UUCP (Kurt Baudendistel) (09/06/88)
In article <8809040943.AA28707@rice-chex.ai.mit.edu> tmb@ganymede.UUCP
discusses Doug Schmidts comments on the [] operator taking only one
argument and how this jives with easily implementable multi-dimensional
arrays.
it is possible to implement multi-dimensional arrays using the ``normal''
[] notations. to do this, you have to implement, dynamically, the array
dimensionality:
md_array A(3); // declare 3-d array
A[0] -> returns first 2-d array of A
type is ``2-d array''
A[0][1] -> return second 1-d array of previous
type is ``1-d array''
A[0][1][2] -> returns third element of previous
type is ``scalar'' (perhaps, double)
for me, this is just too inefficient. i use the following notation
in a vector (1-d) / matrix (2-d) implementation:
doubleVec a(4); // declare 4-element, 1-d array
// of doubles
a(0) * -> returns first element of vector a
type is double
a(0,1) -> returns vector consisting of elements 0-1 of a
type is doubleVec
doubleMat A(4,4); // declare 4x4 element, 2-d array
// of doubles
A(0,0) -> returns first element of array A
type is double
A(1) * -> returns vector consisting of second row of A
type is doubleVec
i could, of course, have used the [] notation for the *'d example lines,
but i chose to use just the () notation, keeping the ``look'' and feel
of vectors and matrices all their own. is this functional or operational
syntax in its usage here?
note also that i could have used double [] notation A[0][0] to get
the first element of array A, but for efficiency reasons, i chose to
use a single level operation of A(0,0) rather that the two-level
operation required to use [] twice.
you can argue about the merits of [] notation over () notation and
whether or not to allow multiple arguments to [], but i think that each
has its place.
--
Kurt Baudendistel [GRA McClellan]
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332
USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!baud
INTERNET: baud@gteedsp.gatech.edusmart@ditmela.oz (Robert Smart) (09/08/88)
In article <8166@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: > ``subscript argument'' runs into a problem with C. a[1,2,3] is > perfectly legal C and C++ (provided a is of a suitable type). > Here ``a'' is subscripted by the comma expression (1,2,3) whose > value is, of course, 3. The comma expression is a vile infelicity in C. It should be a ";" expression, and thus perfectly compatible with a sequence of expressions within {}s. Then ","s could be reserved for what they are good at: building up a compound object to be the parameter of a procedure or the "index" of a multi-dimensional array or the value of an array or struct (not just in initializations). I realise that the reason for this is that it is incompatible with the syntax of a "for" statement which obviously preceded the invention of the comma expression (which show every sign of being a horrible hack added at the last minute or later). It's too late to fix C, but what happened to rumours of D (or was it P, the next letter in BCPL)? It looks like C++ has been so popular that it has killed any chance of other programming language development in the unix heartland. Bob Smart
karl@haddock.ima.isc.com (Karl Heuer) (09/14/88)
In article <8166@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: >[Douglas C. Schmidt asks about providing multi-dimensional arrays via >overloading the subscript operator instead of the function-call operator] > >I think that an array with multiple dimentions, such as a Fortran >a(1,2,3), or a C++ array accessed (through a dope-vector or something) >using an overloaded operator(): a(1,2,3), is different in several >ways from the C array you get by repeated use of subscripting v[1][2][3]. Certainly. And a `+' meaning string concatenate is different from the `+' meaning integer add. But it can still be convenient to use the same symbol. (In fact, I might want to overload *both* a[1,2,3] and a(1,2,3) with different semantics, for some classes where this would make sense.) >On the other hand, overloading operator[] to take more than one >``sunbcript argument'' runs into a problem with C. a[1,2,3] is >perfectly legal C and C++ (provided a is of a suitable type). I don't find this a compelling argument. I doubt that any serious program uses this `perfectly legal' feature, and little would be lost if it had to be written a[(1,2,3)] to force the comma operator. (This is analogous to the situation for function calls.) To keep the grammar simple, this should apply to all uses of the [] operator, overloaded or not. I'll bet allowing `a[1,2,3]' would break less code than changing the meaning of `int f();' did. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint