In article <34onjm$r1m@noc2.drexel.edu>,
Mike Redford <mredford@impact.drexel.edu> wrote:

[... text deleted ...]

| #include <stdio.h>
| FILE *ioptr;
| int number, INDEX,index;
| char *str1[]={
| " B1F1.DAT",
| " B1F2.DAT",
| " B1F3.DAT"

Remove the leading space in each filename.  DOS has a problem with
spaces in a filename.

[... remaning code deleted ...]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Paul-Joseph de Werk               | Hardware Installation/Setup
Draconian Software & Consulting   | Software Installation
PO Box 27981                      | Specialized Software Development
Fresno, CA  93729-7981            | Software & Language Training/Tutoring
paul-joseph_de_werk@csufresno.edu |
pdewerk@mondrian.csufresno.edu    |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

****************************************************************
Why can't process this string str1, and pass it
to fopen and be able to open the dos file?
Please test this on Borlandc or Mcrosoft C or C++.
Using the Debuger, you will see that str1[0],
str1[1] and str1[2] are okay under watch.
However, when pass to file fopen , it does not
open. This is basic in C/C++. This puzzle is
rather fasinating You must try it to see
what I am talking about.
Thanks all those who have contributed so far.
Please mail your findings plus suggestions ,
directly to me.
Thanks yu all!
******************************** Program Follows****************
#include <stdio.h>
FILE *ioptr;
int number, INDEX,index;
char *str1[]={
" B1F1.DAT",
" B1F2.DAT",
" B1F3.DAT"
};

int main(void)
{
for (index=0;index<=2; index++)
   {
  ioptr = fopen (str1[index], "r"); ??????????????
  if (ioptr==NULL)
 {

    fprintf(stderr, "Cannot open input file.\n");
    return 1;
 }
 else
  {
  printf("Can open input file.\n");
  }
 }
 fclose(ioptr);
return 0;
}

In article <34onjm$r1m@noc2.drexel.edu>,
Mike Redford <mredford@impact.drexel.edu> wrote:
>****************************************************************
>Why can't process this string str1, and pass it
>to fopen and be able to open the dos file?
>Please test this on Borlandc or Mcrosoft C or C++.
>Using the Debuger, you will see that str1[0],
>str1[1] and str1[2] are okay under watch.
>However, when pass to file fopen , it does not
>open. This is basic in C/C++. This puzzle is
>rather fasinating You must try it to see
>what I am talking about.
>Thanks all those who have contributed so far.
>Please mail your findings plus suggestions ,
>directly to me.
>Thanks yu all!


    [ ... program deleted ... ]

    Could you explain what your post had to do
    about the C standard, the C++ standard, the
    "struct hack", or overloading the non-existent
    operator[][]?

    In the future, I'd suggest posting in the
    relevant newsgroup (comp.lang.c) and asking
    for help if you're really stumped.  And pick
    a reasonable subject too, rather than blindly
    replying to unrelated threads.  Demonstrating
    the ability to read helps much in forming
    first impressions.

    follow-ups to alt.usage.english
--
Maurice S. Barnum               ==    I speak for me, not my employer.
xmsb@genghis.borland.com        ||    "There is no confusion like the
mosigbit@deeptht.armory.com     ||    confusion of a simple mind."
mbarnum@nyx.cs.du.edu           ==       -- F. Scott Fitzgerald

In article <MATT.94Aug4171906@physics5.berkeley.edu> matt@physics.berkeley.edu writes:
>
>My complaint about C++ isn't that the language has poor array support
>(and string support, and...), but rather that the language doesn't yet
>have a standard class library.  I certainly hope that the folks who
>design the array classes in the standard class library do keep the
>needs of numerical programmers in mind.

 Kent Budge's numerical array class proposal was accepted
at Waterloo. Designed just for physicists Matt!

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <31rrek$pue@ncar.ucar.edu>
           kuehn@citadel.scd.ucar.edu "Jeff Kuehn" writes:
>
> There of course is the argument put forth the the C++-hardcore:
>
>         "just construct a class for MD arrays"
>
> Obviously, only suggested by people who've (a) never tried doing this and
> (b) don't care about performance... ;-)

How about:

   template<class X> class Array2d<X> {
   public:
      Array2d_Ref<X> operator[](int ix)
      { return Array2d_Ref<X>(this, ix); };

      X& at(int ix, int iy);
      ...etc...
   };

   template<class X> class Array2d_Ref<X> {
   public:
      Array2d_Ref(Array2d<X>* arr, int ix)
      { array = arr; index = ix; };

      X& operator[](int iy)
      { return array->at(index, iy); };
   private:
      Array2d<X>* array;
      int index;
   };

IMO this is both (a) simple and (b) reasonably efficient (if you are
really concerned with efficiency you can always use array.at(x,y)
instead of array[x][y], but I would guess there wouldn't be much
difference on a good optimizing compiler.

Unless I'm missing something, of course.

--
Phil Hunt

In article <31rrek$pue@ncar.ucar.edu>,
Jeff Kuehn <kuehn@citadel.scd.ucar.edu> wrote:
>C++ *needs* real arrays, if we're ever going to escape the prophecy:
>
> "I don't know what language will be used for numerical modelling
> in the 21st century, but it will be called Fortran."

Perhaps I'm disqualified by virtue of understanding the Fortran 90 standard
better than I do the C++ draft, but I'm not alarmed that Fortran might
continue to be the favorite numerical modeling language in the 21st century.
In making C++ please everybody, we risk making it please nobody.

Instead, I'd wish that some vendors would put a lot of work into making their
Fortran and C++ implementations interoperate smoothly (a much bigger challenge
than for Fortran vs. C), so that programmers can use Fortran for their
numerical kernels and C++ for everything else; or so they can build prototypes
rapidly in C++ and later migrate the kernels to Fortran.

Your Fortran friends are right that so long as the C++ community is willing to
build "boolean" and "string" into the standard but not willing to build in
multidimensional arrays (or adopt certain semantic restrictions that make
Fortran more susceptible to optimization), Fortran will have some advantages.

They're wrong about OOP, though. Fortran 90 has overloading and generics,
but lacks true polymorphism.
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com

In article <sjcCu20Lx.7Cn@netcom.com> sjc@netcom.com (Steven Correll) writes:

> Your Fortran friends are right that so long as the C++ community is
> willing to build "boolean" and "string" into the standard but not
> willing to build in multidimensional arrays (or adopt certain
> semantic restrictions that make Fortran more susceptible to
> optimization), Fortran will have some advantages.

But the string class isn't being built into the language!  It's going
to be built into the standard class library.  (I admit that the
distinction between the language and the library is sometimes a bit
fuzzy, of course.  Is the class xalloc part of the library, or the
language?)

I hope that multidimensional numerical arrays will also be part of the
standard class library.  I also hope that they will be designed in
such a way so that efficient implementations are possible, and that
compiler vendors will take the trouble to implement them efficiently.
(Efficient implementations of library routines may well depend on
non-portable or even undocumented language extensions.  The interface
should be standardized, but the implementation ought to be written for
maximum efficiency on whatever platform it runs on.)

If a well-designed numerical array class library does become part of
the C++ standard class library, then I really don't see much reason
why numerical programmers should use Fortran.  You'd be surprised just
how much "numerical" code involves memory management and data
structures that could be implemented much more easily in an object-
oriented language.
--

                               --matt

In article <MATT.94Aug5111717@physics5.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>In article <sjcCu20Lx.7Cn@netcom.com> sjc@netcom.com (Steven Correll) writes:
>
>> Your Fortran friends are right that so long as the C++ community is
>> willing to build "boolean" and "string" into the standard but not
>> willing to build in multidimensional arrays (or adopt certain
>> semantic restrictions that make Fortran more susceptible to
>> optimization), Fortran will have some advantages.
>
>But the string class isn't being built into the language!  It's going
>to be built into the standard class library.  (I admit that the
>distinction between the language and the library is sometimes a bit
>fuzzy, of course.  Is the class xalloc part of the library, or the
>language?)

 It's fuzzy because it's a distinction without a difference. The string
class is part of C++. Its specification lives in a chapter entitled "Library"
rather than, say, a chapter entitled "Expression". Other than having to look
in the right chapter of the standard, I can't see how this makes any difference
whatsoever to a user of the language.
 -- Pete

In article <sjcCu20Lx.7Cn@netcom.com>, sjc@netcom.com (Steven Correll) writes:
|> In article <31rrek$pue@ncar.ucar.edu>,
|> Jeff Kuehn <kuehn@citadel.scd.ucar.edu> wrote:
|> >C++ *needs* real arrays, if we're ever going to escape the prophecy:
|> >
|> > "I don't know what language will be used for numerical modelling
|> > in the 21st century, but it will be called Fortran."
|>
|> Perhaps I'm disqualified by virtue of understanding the Fortran 90 standard
|> better than I do the C++ draft, but I'm not alarmed that Fortran might
|> continue to be the favorite numerical modeling language in the 21st century.
|> In making C++ please everybody, we risk making it please nobody.
|>
|> Instead, I'd wish that some vendors would put a lot of work into making their
|> Fortran and C++ implementations interoperate smoothly (a much bigger challenge
|> than for Fortran vs. C), so that programmers can use Fortran for their
|> numerical kernels and C++ for everything else; or so they can build prototypes
|> rapidly in C++ and later migrate the kernels to Fortran.

  In what important way is it harder for C++ to interoperate with
FORTRAN?  By writing C++ array classes with FORTRAN data layout and
calling extern "FORTRAN" functions, C++ and FORTRAN can work together
quite nicely.  In fact we have written wrappers for LAPACK this way
and then integrated the array classes with C++ data layout arrays.
The uniform handling of packed and sparse arrays is quite appealing,
as is the consistent use of operator overloading and the ability to
use arbitrary data types in the arrays and matrices.

  Multidimensional arrays are not the problem with C++ vs FORTRAN.
The problem is pointer aliasing.  Novice or expert code in C++ will
out-perform FORTRAN, but middling code in FORTRAN will win and there
are few experts in C++ working on numerical applications. lapack++
is the important exception and I would look there for a standard
numerical array system.


--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

>In article <sjcCu20Lx.7Cn@netcom.com>, sjc@netcom.com (Steven Correll) writes:
>|> Instead, I'd wish that some vendors would put a lot of work into making their
>|> Fortran and C++ implementations interoperate smoothly (a much bigger challenge
>|> than for Fortran vs. C)...

In article <Cu2ynB.9G4@hawnews.watson.ibm.com>,
John Barton <jjb@watson.ibm.com> wrote:
>  In what important way is it harder for C++ to interoperate with FORTRAN?

I was thinking of runtime issues: e.g., in the best of all possible worlds
you'd like exceptions to work sensibly when languages alternate in the call
chain. No rocket science required, but for some vendors it's extra work. There
are also implementation issues: e.g., the source-to-linker mapping of names
is more complicated for C++ than for C (perhaps you want an "extern Fortran"
clause in the C++ compiler to hide all such issues from the user).

More generally, when a C construct has no Fortran equivalent, vendors often
extend Fortran (e.g. a "%val()" to pass an actual argument by value); because
C++ is richer than C, there's an opportunity for many more such extensions. I
haven't enumerated them to see whether any of them is worth the trouble, but
I'd guess that some are.

As you say, one can often get along fine without such special assistance--at
worst, you just restrict the C++/Fortran interface to use the C subset of C++.
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com

In article <31rrek$pue@ncar.ucar.edu> kuehn@citadel.scd.ucar.edu (Jeff Kuehn) writes:
>Let me start out by saying that I understand the arguments which go along
>with both sides of the multidimensional array issue...

Two questions:

1) What multidimensional array issue?

2) Are you *sure you understand the issues?  I'm not convinced.  You don't
   even seem to be aware of the fact that both C and C++ already provide
   programmers with the ability to declare and use multidimensional arrays.

   Example:

 int three_d[10][20][30];
 int i, j, k;

  ... three_d[i][j][k] ...


>I work in the computing facility of a large national lab and many of my
>co-workers are Fortran programmers because of the reluctance of standards
>committees' to add *real* multidimensional array support to C and C++...

Please define what *you* mean by `real'  multidimensional array support.

(As far as I'm concerned, C and C++ already *have* `real' support for
multidimensional arrays.  What *specifically* do you find lacking?)

>...  Friends in several engineering firms nation wide report the same thing:
>
> "Fortran is *the* choice for scientific/numerical modeling,
> because array handling is too clumsy in C and C++."

Just making an unfounded claim like this doesn't make it true, regardless
of how many silly people say it.

If ``array handling'' (whatever that is) in C and C++ is ``too clumsy''
then maybe one of these days someone will make some effort to demonstrate
that fact clearly and unambiguously.  Until then, it is silly to talk
about people's (perhaps ill-founded) perceptions in a vacuum.

>I've argued with them until I am blue in the face, but they won't give up
>their arrays, period...

Fortunately, they don't have to.  Both C and C++ have multidimensional
arrays.

>C++ *needs* real arrays...

Fortunately, it already has them.

>While much of this has been typed in a tongue-in-cheek fashion, I do wish
>to convey that this is a serious issue...

So far, you haven't succeded.

> -- without more complete support for
>arrays, the usefulness and applicability of C++ is seriously limited for
>a large group of programmers.

Maybe if you tried defining what you mean by ``more complete support''
somebody (other than you) would be able to get an inkling of what the
blazes you think is missing from C and C++.

P.S.  I should mention that some people in the ongoing C standardization
committee also have the idea that C can be improved with respect to the
facilities it offers for manipulating arrays.  *They* however have actually
gone to the trouble of noting specific problems, and also proposing very
specific and detailed solutions.  (Contacy Tom MacDonald <tam@cray.com>
for further information.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

kuehn@citadel.scd.ucar.edu (Jeff Kuehn) writes:

 [[ Lots of text deleted]]

>C++ *needs* real arrays, if we're ever going to escape the prophecy:

I can't agree more.

> "I don't know what language will be used for numerical modelling
> in the 21st century, but it will be called Fortran."

If the numerical C/C++ groups in the Standards Commitees (if they exist)
cannot convince their colleages that something must be done. Then C++
will probably be lost to the Scientific programming community in the future.

Despite its power, speed ,accuracy and ease of use must be in the equation.

>(unless of course, you'd like to see this come true.)

>arrays, the usefulness and applicability of C++ is seriously limited for
>a large group of programmers.

True!.

just my 2 cents worth.
-Mark.

In article <31rrek$pue@ncar.ucar.edu> kuehn@citadel.scd.ucar.edu (Jeff Kuehn) writes:

> There of course is the argument put forth the the C++-hardcore:
>
>  "just construct a class for MD arrays"
>
> Obviously, only suggested by people who've (a) never tried doing this and
> (b) don't care about performance... ;-)

It's the right argument, though; I would simply remove that "just".  I
have tried writing a multi-dimensional array class, and I realize that
this task is nontrivial, but it's still the right answer.

My complaint about C++ isn't that the language has poor array support
(and string support, and...), but rather that the language doesn't yet
have a standard class library.  I certainly hope that the folks who
design the array classes in the standard class library do keep the
needs of numerical programmers in mind.

--
       Matt Austern                       "Se non e vero, e ben trovato"

Let me start out by saying that I understand the arguments which go along
with both sides of the multidimensional array issue... but let me offer
another perspective.  (forgive me for trying to explain someone elses'
opinion, but for reasons which will soon become obvious, they don't
read this group.)

I work in the computing facility of a large national lab and many of my
co-workers are Fortran programmers because of the reluctance of standards
committees' reluctance to add *real* multidimensional array support to C and
C++.  That's right.  Believe it or not this community of programmers has almost
unanimously decided that the availability of MD arrays is more important than
all of the other features C and C++ offer *combined*.  Furthermore, they are
not alone.  Friends in several engineering firms nation wide report the same
thing:

 "Fortran is *the* choice for scientific/numerical modeling,
 because array handling is too clumsy in C and C++."

I've argued with them until I am blue in the face, but they won't give up
their arrays, period.  I should also point out this is *not* a group of
people whom I would characterize as being resistant to change.  For over
two decades, these scientists and engineers have been on the leading edge
of software and hardware technology.  They bought the first-ever Cray-1 back
in 1976 and wrote a compiler and operating system for it with the help of
programmers at Los Alamos and Cray Research (who delivered bare iron).  They
have written codes for multiprocessor and massively parallel architectures
most programmers have never heard of.  This facility saw Unix(tm) looming on
the horizon and migrated to it en-mass from a wide variety of firmly
entrenched systems.  And at every step of the way, they have religously
redesigned their codes to take advantage of new architectures and operating
systems.  They *are* willing to change, but only to something that they see
as "better".  A language without MD arrays does not qualify as "better"
for them.  To quote another Fortraner:

 "If C++ is so great, why can't it handle a simple data structure
 like a multidimensional array as well as my 'crufty' Fortran
 compiler can?  Besides what about Fortran 90 for that object
 orientation stuff?"

Certainly I am *not* going to hold Fortran up as some kind of paragon among
programming languages.  However, as the only 35 year old computer language
still in wide use (Algol is effectively dead, Lisp has never made it out of
academic settings, and I refuse to count Cobol as a programming language,
even though some of you will likely put Fortran under the same category ;-)
I think that there is something to be learned from Fortran.  (What other
language has warranted four ANSI standards? (66, 77, 90, and the upcoming
95/96 standard... 2000 has already been mentioned as well.))

There of course is the argument put forth the the C++-hardcore:

 "just construct a class for MD arrays"

Obviously, only suggested by people who've (a) never tried doing this and
(b) don't care about performance... ;-)

C++ *needs* real arrays, if we're ever going to escape the prophecy:

 "I don't know what language will be used for numerical modelling
 in the 21st century, but it will be called Fortran."

(unless of course, you'd like to see this come true.)

While much of this has been typed in a tongue-in-cheek fashion, I do wish
to convey that this is a serious issue -- without more complete support for
arrays, the usefulness and applicability of C++ is seriously limited for
a large group of programmers.

--Jeff

In article <30etuk$b17@gap.cco.caltech.edu> mhagger@rigel.krl.caltech.edu (Michael Haggerty) writes:
>The number of posts about overloading operator[][] is a good
>indication that this is an issue which would benefit from change.

Yes folks, that's right.  Just get five of your friends together and
have them all make posting here saying that ``WE INSIST THAT LEFT-
HANDED WANGLES ARE CRUCIAL TO THE FUTURE OF C++, AND THAT THEY OUGHT
TO BE ADDED TO THE LANGUAGE IMMEDIATELY.''  That's really all you
need to do to convince Mr. Haggerty, that left-handed wangles are the
greatest thing since sliced bread.  Don't even bother with little
details (like prior implementation experience and/or proper inte-
greation with the rest of the EXITING language).  Step right up
and demand your own left-handed wangle in the language today!

(Design by mob rule.  What a concept!)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In an article, Michael Haggerty (mhagger@rigel.krl.caltech.edu) wrote:
[stuff deleted]

: , I suggest the next-best and less ambiguous interpretation that the
: above operator be invoked as

:     M[a,b]

Does C++ allow 'operator ()' to take parameters ?

i.e.

class x {
  int a;
  int operator() { return a; }
  int operator( int y ) { return a * y; }
  int operator( int y, int z ) { return a * y * z; }
   ...
}

This seems to be similar to the issue for [].

Michael T.

In article <30etuk$b17@gap.cco.caltech.edu> mhagger@rigel.krl.caltech.edu (Michael Haggerty) writes:
> The number of posts about overloading operator[][] is a good
> indication that this is an issue which would benefit from change.  Of

...

> , I suggest the next-best and less ambiguous interpretation that the
> above operator be invoked as
>
>     M[a,b]
>
...

>
> What does everyone think?
>
> Michael Haggerty
> mhagger@altair.krl.caltech.edu



I don't know what everyone thinks, but I think this is a very reasonable
suggestion.  I have been disturbed by the inability to overload [][]
myself.  The comma in C is already pretty nasty to begin with given that
in some instances it's an operator and in other instances it's a parameter
or argument separator.  I would NEVER, EVER overload comma.  (Well, maybe
never.)

If I had a vote, then I'd vote for this proposal.

Joe Wilson
<A HREF="http://www.cis.ufl.edu/~jnw/">jnw@cis.ufl.edu</A>

 In article <Ct5u37.FrM@world.std.com>
 miket@world.std.com (Michael Trachtman) writes:

>   In an article, Michael Haggerty (mhagger@rigel.krl.caltech.edu) wrote:
>   [stuff deleted]
>
>   : , I suggest the next-best and less ambiguous interpretation that the
>   : above operator be invoked as
>
>   :     M[a,b]
>
>   Does C++ allow 'operator ()' to take parameters ?

yes. i use it in my error class like this:

////////////////////////////////////
class Error {
public:
  Error(const char* cl) {_cls = new char[20]; strcpy(_cls,cl);}
  ~Error() {delete[] _cls;}
  void operator()(int err_code)
    {cerr << "class " << _cls << "fatal error of type: " << err_code << endl;
     exit(err_code);}
  void operator()(const char* msg1,
    const char* msg2 = "",
    const char* msg3 = "")
    {cerr << _cls << " fatal error:" << '\n';
     cerr << msg1 << ": " << msg2 << ' ' << msg3 << endl;
     exit(1);}
private:
  char*  _cls;
};


--
--alan

In article <Ct5u37.FrM@world.std.com> miket@world.std.com (Michael Trachtman) writes:
>
>Does C++ allow 'operator ()' to take parameters ?
>
 Yes.
>
>class x {
>  int a;
>  int operator() { return a; }
>  int operator( int y ) { return a * y; }
>  int operator( int y, int z ) { return a * y * z; }

 Wrong syntax. Try instead:

 int operator() (int y, int z) { .. }

>This seems to be similar to the issue for [].

 At present, [] requires a single parameter.
Unfortunately. I'd like to see it symmetric with operator().
The might break weird and obscure code using the comma
operator:

 x[i,j];

would mean a call to say

 operator[](int,int)

rather than a call to

 operator[]

with (i,j) as the argument. Does anyone care?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <JNW.94Jul19150217@aviator.cis.ufl.edu> jnw@aviator.cis.ufl.edu (Joseph N. Wilson) writes:

>   I don't know what everyone thinks, but I think this is a very reasonable
>   suggestion.  I have been disturbed by the inability to overload [][]
>   myself.  The comma in C is already pretty nasty to begin with given that
>   in some instances it's an operator and in other instances it's a parameter
>   or argument separator.  I would NEVER, EVER overload comma.  (Well, maybe
>   never.)

Unfortunately, this is altering the language's base definition to appease a
specific segment of the C++ user base -- primarly those interested in
mathematical applications. I'm sure it has other applications, however if
you cf. Design and Evolution of C++ by Stroustrup you'll see that there
have been a LOT of proposals for things that would be extremely useful (eg.
the "noalias" keyword) to some folks, but these proposals have invariably
been rejected because the problems associated with their implementation
is (perceived) not being worth the (limited) benefits they provide.

For example, I completely support such things as parameters to constructors
when allocating arrays and I also support the "inherited" keyword.  This
latter one I believe many agree would be useful to a LARGE portion of the
C++ community, yet Dag Bruck withdrew the proposal because A.) a sort-of
okay workaround can be hacked (hacked == anything not directly supported by
the language :-)) using typedef and B.) it wasn't so overwhelmingly
necessary/useful that its existence could be completely justified.  Oh
well.

Another problem with overloading the [][] operator is defining its
characteristics.  For example, what happens in a situation where:

struct Vector
{
   elem_t *elems;
   elem_t operator [] ( int a ) { return elems[a]; }
};

struct Matrix
{
   Vector **vector;
   Vector *operator [] (int a) { return vector[a]; }
   elem_t  operator [][] (int a, int b ) { return vector[a][b]; }
};

Matrix m;

   elem_t e = m[0][0];

There is an element of ambiguity right there.

Finally, there are some who say that overloading [] is pretty noxious as
is, since under most situations it implies array indexing, yet in the
special cases when it is overloaded it may not have very obvious
connotations.  For example, an array of matrices:

Matrix *m;

   x = m[matrix_num][row][column];

Let's talk ambiguous semantics, no?

Just my $0.02,

Brian




--
+---------------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics       |
| Box 90315             |---------------------------------------------|
| Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
+- "Style distinguishes excellence from accomplishment" - J. Coplien -+

In article <MATT.94Jul19171056@physics5.berkeley.edu> matt@physics5.berkeley.edu (Matt Austern) writes:

>   That's one reason why I think that introducing operator[][] is a bad
>   idea.  The other reason is that this isn't a general enough solution
>   to the problem: operator[][] is fine for two-dimensional arrays, but
>   what if you want a three-dimensional array? Does this mean that we
>   ought to have operator[], operator[][], and operator[][][]?  Surely
>   not.  Surely any decent solution to the general problem of
>   n-dimensional array syntax should be more than a set of special cases.

Exactly.  As I stated earlier, the very fact that [] can be overloaded
causes some semantic problems (the "[] as array indexing vs. [] as an
operator issue").  Also, I think (and I would venture that many would
agree) that solving a very domain specific problem (Seriously, a specific
addition to the language to support 2D matrices?!) by a language feature is
not good design.

If a good solution can be devised that solves the problem for N-dimensional
bracket use, then THAT should definitely be considered.  But adding an
operator [][] seems shortsighted because of the obvious reasons (what about
three-dimensional arrays, etc. etc.)

>   Just because operator[][] is a bad solution, though, doesn't mean that
>   we shouldn't do anything.  I prefer the other idea: allowing
>   operator[] to be defined with any number of arguments, just like
>   operator().  I was actually rather surprised when I first realized
>   that operator[] was restricted to a single argument.  Removing this
>   restriction would make the language cleaner and would make it easier
>   to write multidimensional array classes.

Sure, this isn't a bad way of doing things.  However, I'm not familiar
enough with the rationale re: allowing only a single parameter to operator
[] to make a sweeping statement with regards to its "goodness" or
"badness".  There are a lot of good reasons for the way C++ was designed.
As a matter of fact, I'd say out of the many many many things that I've
come up with as "problems" or "good extensions" to the language, only two
have actually stuck with me as still being worth of contention
(specifically, arguments to constructors when creating an array of objects,
and the "inherited"/"super" keyword).


Brian
--
+---------------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics       |
| Box 90315             |---------------------------------------------|
| Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
+- "Style distinguishes excellence from accomplishment" - J. Coplien -+

In article <BWH.94Jul19180526@kato.prl.ufl.edu> bwh@kato.prl.ufl.edu (Brian Hook) writes:

> Matrix m;
>
>    elem_t e = m[0][0];
>
> There is an element of ambiguity right there.

The ambiguity is that m[0][0] might mean m.operator[][](0,0), or might
mean (m.operator[](0)).operator[](0).  And yes, that certainly is an
ambiguity.  If operator[][] were added to the C++ language, there
would have to be some rule or set of rules detailing whether something
like this should be taken to mean operator[][] or not.

I'm sure that rules like this could be written, but I'll bet they'd be
complicated enough that some programmers would end up making subtle
and hard-to-diagnose mistakes.

That's one reason why I think that introducing operator[][] is a bad
idea.  The other reason is that this isn't a general enough solution
to the problem: operator[][] is fine for two-dimensional arrays, but
what if you want a three-dimensional array? Does this mean that we
ought to have operator[], operator[][], and operator[][][]?  Surely
not.  Surely any decent solution to the general problem of
n-dimensional array syntax should be more than a set of special cases.

Just because operator[][] is a bad solution, though, doesn't mean that
we shouldn't do anything.  I prefer the other idea: allowing
operator[] to be defined with any number of arguments, just like
operator().  I was actually rather surprised when I first realized
that operator[] was restricted to a single argument.  Removing this
restriction would make the language cleaner and would make it easier
to write multidimensional array classes.

(As others have pointed out, though, it could potentially break
existing code.  I don't think this is a serious problem: it wouldn't
quietly change the meaning of existing code, but rather would turn
presently legal code into illegal code.  Still, breaking existing a
code is always a bad thing if it can be avoided.)


--
       Matt Austern                       "Se non e vero, e ben trovato"

In article <30etuk$b17@gap.cco.caltech.edu>,
Michael Haggerty <mhagger@rigel.krl.caltech.edu> wrote:
>Since there seems to be great resistance to letting
>
>    operator[](int a, int b)
>
>be called through
>
>    M[a][b]

What resistance?  It should work well.  It can't break any existing code
because no existing classes use it.

Consider a class with two versions, the single-dimensional version
operator[](int) and the two-dimensional version operator[](int,int).
Using m[a][b] would call the two-dimensional version.  In the case
where no two-dimensional version existed, it would be a normal one-
dimensional version call as it has been all along.  To explicitly
call the one-dimensional version and still add a 2nd subscript to
the return value of the call, just add parentheses: (m[1])[b], which
would be very rarely used, because if you define operator[](int,int)
it implies you want to use it.

Why isn't this already in the standard?  What is the source of the great
resistance you mention?  Are there any good reasons for it?

In article <BWH.94Jul19180526@kato.prl.ufl.edu>,
Brian Hook <bwh@kato.prl.ufl.edu> wrote:
>Another problem with overloading the [][] operator is defining its
>characteristics.  For example, what happens in a situation where:
...
>Let's talk ambiguous semantics, no?

See my previous message on this subject.  There need be no problems
with ambiguities.  But I don't like operator[][].  Just adding more
arguments to operator[] and invoking it as x[a][b][c]... is better for
several reasons.

One reason is that the two operator sequence [][] would be ambiguous
with the single operator [][] and the ambiguity would have to be
resolved at high level by the parser.  That would complicate a lot of
compilers.  Doing it my way, each [] would be seen as a separate
operator but would tell the compiler to add an argument to the call to
the first operator[] when appropriate instead of calling another
operator[] for each.  In my parser, and probably in most others too,
that would be almost trivial to implement.

Another reason is that you can't have an infinite number of operators,
e.g., operator[], operator[][], operator[][][], etc.  So it's better
to just have one with multiple arguments, invoked as x[a][b][c] but
calling operator[](int,int,int).

In article <MATT.94Jul19171056@physics5.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>(As others have pointed out, though, it could potentially break
>existing code.  I don't think this is a serious problem: it wouldn't
>quietly change the meaning of existing code, but rather would turn
>presently legal code into illegal code.  Still, breaking existing a
>code is always a bad thing if it can be avoided.)

Doing it my way you could invoke it as m[a][b][c][d] and it wouldn't
break any existing code.  The existence of operator[](int,int,int,int)
in a class would cause m[a][b][c][d] to invoke it.  In cases where
m[a][b][c][d] is used with its former meaning, the class has no
operator[](int,int,int,int) so it wouldn't be a problem.  If there
were more than one different numbers of dimensions implemented in a
class, it would use the biggest that would fit, and you would use
parentheses to explicitly use the others, such as (m[a][b][c])[d],
but there are probably no cases where you would ever want to do that.

But in any case, it wouldn't break any existing code, wouldn't be hard
to compile, wouldn't be hard to use, and I can't really see any arguments
at all against it.  If someone says it's harder to compile than it looks
or someone says (m[a][b][c])[d] is more of a problem than I think it is,
then as an alternative I could propose using m[[a][b][c][d]] as the
syntax, which would be easier to compile and would totally eliminate all
questions of ambiguity, but would not be quite as neat.  m[[a][b][c][d]]
would be better than m[a,b,c,d] or m[a;b;c;d] because the commas break
existing code and the semicolons would annoy novices by making it hard
to remember whether they should use commas or semicolons.

In article <BWH.94Jul19202729@kato.prl.ufl.edu> bwh@kato.prl.ufl.edu (Brian Hook) writes:
...

> If a good solution can be devised that solves the problem for N-dimensional
> bracket use, then THAT should definitely be considered.  But adding an
> operator [][] seems shortsighted because of the obvious reasons (what about
> three-dimensional arrays, etc. etc.)

I agree with that.  I have been frustrated by the apparent need to
overload operator[][] instead of being able to overload [,,,].  As I
see it, these problems with [][][][]...  came from C using that
notation rather than [,,,, ... ].  I think C blew it there.  I think
that it would be more useful in C++ to be able to overload [] with
more than one argument than to maintain consistency with C.

I would be happy to be able to treat [][] just as it is treated today, but
still be able to overload [,,].

>
> Brian
> --
> +---------------------------------------------------------------------+
> | Brian Hook            | Specializing in real-time 3D graphics       |
> | Box 90315             |---------------------------------------------|
> | Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
> +- "Style distinguishes excellence from accomplishment" - J. Coplien -+


Joe Wilson
<A HREF="http://www.cis.ufl.edu/~jnw/">jnw@cis.ufl.edu</A>

I think this entire issue goes away if you decide that operator[]
is not the subscripting operator at all.  Someone writing a C language
doc. back in the dark ages slipped up.  They meant to write
"projection operator".  For a 2D array "a" in C, a[4] is a one
dimensional array and a[4][3] is projection followed by projection
to give an element.  Only for one dimensional arrays is operator[]
subscripting, merely because projection in one dimension is
subscripting.

Using operator[] for multi-dimensional projection and operator() for
multi-dimensional subscripting makes for more readable array code
in my opinion.  Ok, so we didn't pick C++ for readability...

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <30i25h$eip@crl5.crl.com> es@crl.com (Eric Smith) writes:
>In article <30etuk$b17@gap.cco.caltech.edu>,
>Michael Haggerty <mhagger@rigel.krl.caltech.edu> wrote:
>>Since there seems to be great resistance to letting
>>
>>    operator[](int a, int b)
>>
>>be called through
>>
>>    M[a][b]
>
>What resistance?  It should work well.  It can't break any existing code
>because no existing classes use it.

 I'm confused. There is no such thing as a member function

 X::opertor[](int,int)

Subscript member functions may have only one argument.
>
>Why isn't this already in the standard?

 Well, X::operator[](parameter-list) isnt in the ARM
or the current WD because no one proposed it. A brief discussion
indicates it might have passed had such a proposal been put.
But last week it was decided to move the WD into the ISO processes,
which means extensions like this one will are less likely
to be accepted at this point in time.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

jnw@aviator.cis.ufl.edu (Joseph N. Wilson) writes:

>In article <30etuk$b17@gap.cco.caltech.edu> mhagger@rigel.krl.caltech.edu (Michael Haggerty) writes:
>> The number of posts about overloading operator[][] is a good
>> indication that this is an issue which would benefit from change.  Of

>...

>> , I suggest the next-best and less ambiguous interpretation that the
>> above operator be invoked as
>>
>>     M[a,b]
>>
>...

>>
>> What does everyone think?

>I don't know what everyone thinks, but I think this is a very reasonable
>suggestion.  I have been disturbed by the inability to overload [][]
>myself.
...
>If I had a vote, then I'd vote for this proposal.



Are you suggesting that the standards committee should alter the
operator [] so that confusion about the supposed "operator[][]" could
be avoided ?  I'm _not_ sure but I suspect they're rather busy with
other aspects of the language.

Surely this could just be included in the FAQ on comp.lang.c++ which is
where this question manifests itself (mostly). Augmented, in desperate
cases, with recourse to TFM :-)


A standard array/matrix class library might, let us hope, put the
subject to rest once & for-all.



Cheers    Rob

In article <1994Jul20.105900.18474@ucl.ac.uk> ucecb09@ucl.ac.uk (Mr Robert Byrne) writes:
...
> >If I had a vote, then I'd vote for this proposal.
>
>
>
> Are you suggesting that the standards committee should alter the
> operator [] so that confusion about the supposed "operator[][]" could
> be avoided ?  I'm _not_ sure but I suspect they're rather busy with
> other aspects of the language.

No, this means that if I (being blissfully ignorant of any of the
semantic downsides of [,,]) were on the standards committee, I would
vote for such a proposal if it were put forward.

...
> A standard array/matrix class library might, let us hope, put the
> subject to rest once & for-all.
>

I don't think a standard array/matrix class library would solve this.
This problem is experienced by people who want to overload [] in their
own special way for n-dimensional matrix-like types, without having to
define a bazillion different n-1, n-2, ... 1 dimensional other types
that have to be constructable via projection from n-dimensional
objects.

>
>
> Cheers    Rob
>
>

Joe Wilson
<A HREF="http://www.cis.ufl.edu/~jnw/">jnw@cis.ufl.edu</A>

>>>>> Brian Hook <bwh@kato.prl.ufl.edu> writes:

> As a matter of fact, I'd say out of the many many many things that I've
> come up with as "problems" or "good extensions" to the language, only two
> have actually stuck with me as still being worth of contention
> (specifically, arguments to constructors when creating an array of objects,

What do you mean?  What's wrong with

A a[4] = { A (1,2), A (3,4), A (4,5), 0 };

?

Jason

In article <JASON.94Jul24194011@deneb.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>>>>> Brian Hook <bwh@kato.prl.ufl.edu> writes:
>
>> As a matter of fact, I'd say out of the many many many things that I've
>> come up with as "problems" or "good extensions" to the language, only two
>> have actually stuck with me as still being worth of contention
>> (specifically, arguments to constructors when creating an array of objects,
>
>What do you mean?  What's wrong with
>
>A a[4] = { A (1,2), A (3,4), A (4,5), 0 };

 It doesnt work if the array is a member :-(

 That means that for arrays of T which are members:

 1) T cannot be const
 2) T must have either no constructors or a user defined
 default constructor

Condition 2 is extremely annoying, since having no default
constructor is a useful way to prevent use of an entity
which has not been explicitly initialised and hence ensure
that explicit initialisers are always visible -- useful if
there is no obvious default value.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

The number of posts about overloading operator[][] is a good
indication that this is an issue which would benefit from change.  Of
course it's true that this notation can be kludged together through
the use of a helper class, but that solution is cumbersome and several
widely-used libraries resort to using operator()(a,b) because of the
effort (and often inefficiencies) inherent in the helper-class idiom.
That approach, in turn, is bad because it breaks the handy conventions:

    () implies function call
    [] implies indexing

    While it's true that operator[] currently takes only one argument,
I claim that it would be a great improvement to extend the standard to
allow it to take an arbitrary list of arguments, like operator() can.
Since there seems to be great resistance to letting

    operator[](int a, int b)

be called through

    M[a][b]

, I suggest the next-best and less ambiguous interpretation that the
above operator be invoked as

    M[a,b]

    Of course this construct already has an interpretation--of
invoking the comma operator and the one-operand operator[].  However,
this construct is rare, in the few cases where it is used, it's simple
enough to substitute M[(a,b)], with an explicit set of ()'s to force
the use of the comma operator.  Moreover, the compiler would generate
a warning when such a construct appeared for a class which didn't have
a two-argument braket operator defined, so I don't think that
backwards compatibility is a problem.

    The advantages of avoiding the helper class method are merely
practical, but significant: helper classes are cumbersome, requiring
many lines of code; they require storing information in the helper
class that will anyway be extracted again immediately; and the
two-layer structure makes it more difficult for the
operator[].operator[] pair of functions to cooperate in the resolution
of special cases, etc.

    The advantage of using square brackets instead of parenthesis is
that the square bracket notation gives a strong hint that what is
being done is an array/matrix access and not some more general
function call.  The extension from C-style a[i][j] notation to a new
a[i,j] notation will be welcome to many C++ newcomers and an obvious
changeover for C++ oldtimers.  Of course the old a[i][j] notation
would continue to be used for built-in 2-D arrays; whether that should
be able to be abbreviated as a[i,j] is a less-important issue that
could be decided either way.

What does everyone think?

Michael Haggerty
mhagger@altair.krl.caltech.edu