Path: utzoo!attcan!uunet!edsews!satinfo!teemc!mibte!gamma!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: Declaration of multi-dimensional arrays.
Summary: is already done right
Message-ID: <8166@alice.UUCP>
Date: 4 Sep 88 13:41:49 GMT
References: <8809032205.aa09007@PARIS.ICS.UCI.EDU>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 37

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.