mfinney@inmind.com wrote:
>
> In <59cvaa$9j1@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu (David A.
> Cuthbert) writes:
> >>Perhaps because it gets special treatment is most procedural
> >>languages and the existing C++ syntax is apalling.  The concept of a
> >>multi-dimensional array is very widespread and used frequently (even
> >>outside of math programming!).
> >
> >But this is borrowed from mathematics.  IMHO, it is -- fundamentally
> >-- a mathematical concept.
>
> In that sense, so are single dimensional arrays and most concepts
> in a procedural language.  Certainly arithmetic and logical operators
> are mathematical at their root.  Programming and mathematics are
> linked very closely.  However, making multi-dimensional arrays
> available does *not* mean that we would be adopting something
> purely for mathematical usage.
>
> >A multi-dimensional array is, fundamentally, an n-dimensional vector
> >space (assuming that you haven't overloaded the operators in a
> >horribly non-intuitive way).
>
> Or it can be considered to be a map from a cross product into a
> set.  After all, the elements may or may not be in a number field.
>
> And strictly speaking, even when numeric, when the subscripts
> are integral values they are not in a field because they may
> have zero divisors (in an 8-bit 2's complement ring, 0x10 * 0x10 = 0x00
> and so 0x10 is a zero divisor).  However, that is quibbling.
>
> >I still fail to see how this isn't a mathematics-notation problem.
>
> It isn't a mathematics notation problem any more than single
> dimension arrays or arithmetic is a mathematics notation problem.
> To some degree it is.  But not because its usage is solely for
> mathematics programming.  Only in the sense that programming
> languages and mathematics are very tightly linked.
>
> >I don't see how to add syntax to support this (i.e., what is it
> >called? operator [] (int x, int y, int z)?).  Or should the compiler
> >translate this to [x][y][z]?
>
> >On the whole, I have to agree that the [,,] operator is very useful.
> >However, I don't see a good way to integrate this into C++.
>
> I think that it can be done in just a few paragraphs.  This is poorly worded,
> but for example...
>
> =====================
>
>    1. If a qualified name requires multiple subscript operators, the
> operators on the left can be propagated to the right.  However, a subscript
> cannot be propagated to the right and be replaced in turn by one which was
> propagated from the left.  Thus...
>
>    abc[1].def[3].xyz[5]
>
> can be written as...
>
>    abc[1].def[3].xyz[5]
>    abc[1].def.xyz[3,5]
>    abc.def[1,3].xyz[5]
>    abc.def.xyz[1,3,5]
>
> but not as...
>
>    abc.def[1].xyz[3.5]
>

what about this:

class A
{
public:
  double operator[](int);
};

class B
{
public:
  double operator[](int,int);
};

class C
{
public:
  A xyz;
};

class D
{
public:
  B xyz;
};

class E
{
public:
  C operator[](int,int);
  D operator[](int);
}

E abc;

double x=abc.xyz[1,2,3];
// abc.operator[](1,2).xyz.operator[](3) or
// abc.operator[](1).xyz.operator[](2,3) ?

>    2. Multiple subscripts on a single name can be combined.  So...
>
>    abc[1][3][5]
>
> can be written as any one of...
>
>    abc[1][3][5]
>    abc[1][3,5]
>    abc[1,3][5]
>    abc[1,3,5]
>
> This propagation of subscripts does not affect the semantics of the qualified
> expression in any way.  It is a mere syntatical convenience.
>

What about:

class A
{
public:
  double operator[](int);
};

class B
{
public:
  double operator[](int,int);
};

class C
{
public:
  A operator[](int,int);
  B operator[](int);
};

C c;

double x=c[1,2,3];
// c.operator[](1).operator[](2,3) or c.operator[](1,2).operator[](3) ?

or:

class A
{
public:
  A operator[](int);
  A operator[](int,int);
}

A a;
A b=a[1,2,3];
// a.operator[](1,2).operator[](3)  or a.operator[](1).operator[](2,3) ?


[...]

> =====================
>
> Note that there is no requirement for any changes in data declarations.
> Native support (beyond existing C/C++) is not required for multi-dimensional
> arrays.  No new forms of new and delete are required.  In other words, only
> minor syntatical changes are required for propagating subscripts to the right
> and only a minor extension is required to allow recognition of multiple
> subscript user operators.  But, I believe that it gives us everything that we n
> eed.
> Better syntax and the ability (for example) to define operator[](int, int, int)
> .

The language has enough syntax problems inherited from C. So please
don't add another problem.

You can have *either* the operator[](,) *or* the [,]/[][] equivalence,
but not both (perhaps with the exception of built in arrays, where
no multi-index operator is/can be defined).

And abc[1].xyz[2] is conceptionally different than abc.xyz[1,2]
(or abc.xyz[1][2]), so I strongly dislike making those semantically
equal.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christopher Eltschka wrote:
> mfinney@inmind.com wrote:
> >
> > In <59cvaa$9j1@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu (David

  [ Skiped a long discution about math and multiple dimension array ]

  [ Skiped the beginning of the proposal ]

> >    2. Multiple subscripts on a single name can be combined.  So...
> >
> >    abc[1][3][5]
> >
> > can be written as any one of...
> >
> >    abc[1][3][5]
> >    abc[1][3,5]
> >    abc[1,3][5]
> >    abc[1,3,5]
> >
> > This propagation of subscripts does not affect the semantics of the qualified
> > expression in any way.  It is a mere syntatical convenience.
> >
>
> What about:
>
> class A
> {
> public:
>   double operator[](int);
> };
>
> class B
> {
> public:
>   double operator[](int,int);
> };
>
> class C
> {
> public:
>   A operator[](int,int);
>   B operator[](int);
> };
>
> C c;
>
> double x=c[1,2,3];
> // c.operator[](1).operator[](2,3) or c.operator[](1,2).operator[](3) ?
>
> or:
>
> class A
> {
> public:
>   A operator[](int);
>   A operator[](int,int);
> }
>
> A a;
> A b=a[1,2,3];
> // a.operator[](1,2).operator[](3)  or a.operator[](1).operator[](2,3) ?
>
> [...]
>
> > =====================
> >
> > Note that there is no requirement for any changes in data declarations.
> > Native support (beyond existing C/C++) is not required for multi-dimensional
> > arrays.  No new forms of new and delete are required.  In other words, only
> > minor syntatical changes are required for propagating subscripts to the right
> > and only a minor extension is required to allow recognition of multiple
> > subscript user operators.  But, I believe that it gives us everything that we n
> > eed.
> > Better syntax and the ability (for example) to define operator[](int, int, int)
> > .
>
> The language has enough syntax problems inherited from C. So please
> don't add another problem.

Right

> You can have *either* the operator[](,) *or* the [,]/[][] equivalence,
> but not both (perhaps with the exception of built in arrays, where
> no multi-index operator is/can be defined).

I don't see why that follow.

(1) [,] -> [][] (-> means 'is in fact')
(2) operator[](,) (this operator can take multiples arguments)

(1) and (2) might seem ortogonal: (1) is about syntax and (2) about
semantic. The problem is that it is not clear what you mean by (2):
(2a) 'vec[1][2] means vec.operator[](1,2)' or (2b) 'vec[1,2] means
vec.operator[](1,2)'.

Of course with (1), (2) become equivalent with (2a) and (2b).

The problem with (2a) is that vec[1][2] has a meaning now:
vec.operator[](1).operator[](2) so there is an ambiguity if you
introduce a second meaning.

This might be considered an overloading problem and if both
operator[](T1,T2) and operator[](T3) are defined in a class then
if a in vec[a][b] is convertible to T1 and T2 we have an error.

Or it might be an error just to define two operator[] with differents
number of arguments in a class.

> And abc[1].xyz[2] is conceptionally different than abc.xyz[1,2]
> (or abc.xyz[1][2]), so I strongly dislike making those semantically
> equal.

Absolutly right.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)














































--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <58i0gn$isk@mimsy.cs.umd.edu>, brad@cfar.umd.edu (Brad Stuart) writes:

*Chelly Green (chelly@eden.com) wrote:
*
*: I don't really understand this. People are too obsessed with syntax,
*: which is what you see. The semantics for all of the following can easily
*: be made the same, with appropriate functions/language changes:
*
*:     foo.get( 10, 20 );
*
*:     get( foo, 10, 20 );
*
*:     foo [10] [20];
*
*:     foo( 10, 20 );
*
*:     foo [10,20];
*
*: They can all resolve to the same thing. What is wrong with defining the
*: operator () to accept two parameters, as in the second line (which the
*: language currently allows)?

People too often dismiss syntax as "mere syntax" or "syntatic sugar".

This is a very great mistake.  Notation is extremely important in one's
ability to handle larger and larger conceptual problems.  One of the
major advances Einstein made was not the theory of relativity, but
the origination of tensor notation (which has since been generalized
into the lesser known holor notation for multi-dimensional matricies)
which made thinking and working with vectors *so* much easier.  Not
to mention things like Feinman's diagrams.  There were several notations
(at least three) for matricies last century, but one was so overwhelming
that it completely eclipsed the others.  Notation is *not* merely "syntatic
suger", but essential to the ability to think clearly.  Especially when
abstractions are involved.  Which is more and more the case for OO.

This is why the way that mathematicans write equations has infiltrated
almost all procedural languages (yes, I know that there are exceptions).
Violation of the "expected" syntax invariably causes some major
cognitive dissonance.  Even simple things like the lack of precedence
between * and +.  That has messed me up so many times in languages
that don't have precedence that it isn't funny.  Saving a trivial amount
of effort in the compiler simply isn't worth it.

So, when someone suggests that being able to write foo[x,y,z], I
think that too many people dismiss this too quickly as mere "syntatic
sugar".  Yes, you *could* use any of the forms that you gave
above, but with [] meaning "array subscript" in the remainder of
the language, only foo[x,y,z] makes any kind of real sense.  The
next best alternative was foo[x][y][z] which is appalling hard to
read.  And the reason that so many people keep suggesting the
enhancement.  But the C++ standard committee is too devoted to
keeping every possible wart of C to improve C++ in minor ways.

And yes, adoption of that modification would potentially break some
existing C code -- but none that I have ever worked on in the last
twelve years.  The compiler could easily flag a warning (optionally
suppressed, but required by the standard) of the ambiguity so that
the problem could be fixed and so that it would not "silently" break
existing code.  A lot more code is broken by things like the removal
of implicit "int" in definitions and requiring function prototypes.

Generally, the attitude of the standards committe towards "syntatic
sugar" is not very good.  I personally think that the ability to define
notation is critical, in many cases, to developing readable code.  The
ability to add operators and even different types of brackets would
be *very* nice.  Especially when Unicode is supported as the source
character set and we have all of those *nice* mathematical operators
available.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

<mfinney@inmind.com> wrote:
>People too often dismiss syntax as "mere syntax" or "syntatic sugar".
[...]
>So, when someone suggests that being able to write foo[x,y,z], I
>think that too many people dismiss this too quickly as mere "syntatic
>sugar".  Yes, you *could* use any of the forms that you gave
>above, but with [] meaning "array subscript" in the remainder of
>the language, only foo[x,y,z] makes any kind of real sense.  The
>next best alternative was foo[x][y][z] which is appalling hard to
>read.  And the reason that so many people keep suggesting the
>enhancement.

If you're expecting C++ to look a lot like math, you're expecting way
too much out of the language.

For example, evaluating:

                    4     -1  z
 y = Log  ( x   Tan   --- )  -- all vars long double
               10             x

is written in C/C++ as:

 y = log10l(powl(x, 4.0) * atan2l(z, x));

Why should [] get any special treatment?

If syntax is as important as it seems to be in your case, you should
consider programming in Mathematica.  It's much close to what you
want, offers formatting options, etc.  The above in Mathematica is:

 y = Log[x^4 ArcTan[z, x], 10]

Furthermore, it supports the [,] notation (sort of) that you want.
For example, Foo[x][y][z] can be written as:

 Foo[[x]][[y]][[z]] (* or *)
 Foo[[x, y, z]] (* or *)
 Part[Foo, x, y, z]

[[ ]] is the subscript operator in Mma (instead of [ ]).

Making C/C++ look nice for mathematics problems will benefit one
comparatively small segment of problems at the expense of many
others (including C compatability, in the case of C++).

Also note that C++ is not a very good solution to a number of matrix
problems unless you really know what you're doing (i.e., you're
writing this code for a living).  In most of the existing code, a lot
of unnecessary temporaries will get created (check Deja News for an
article by Steve Karmesin of LANL for details (Sep 11)).

What I usually do for these types of problems in which the final
product has to be a stand-alone executable is to first model the
behavior in Mathematica (or Matlab or Mathcad...) and then translate
the code into C or C++.  Works like a charm almost every time.
--
David A. Cuthbert    Graduate Student, Electrical and Computer Engineering
dac2+@andrew.cmu.edu                            Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <58qdek$7vs@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu (David A. Cuthbert) writes:

*><mfinney@inmind.com> wrote:
*>>People too often dismiss syntax as "mere syntax" or "syntatic sugar".
*>[...]
*>>So, when someone suggests that being able to write foo[x,y,z], I
*>>think that too many people dismiss this too quickly as mere "syntatic
*>>sugar".  Yes, you *could* use any of the forms that you gave
*>>above, but with [] meaning "array subscript" in the remainder of
*>>the language, only foo[x,y,z] makes any kind of real sense.  The
*>>next best alternative was foo[x][y][z] which is appalling hard to
*>>read.  And the reason that so many people keep suggesting the
*>>enhancement.
*>
*>If you're expecting C++ to look a lot like math, you're expecting way
*>too much out of the language.

You seem to have entirely missed the thrust of my message.  The
idea is *not* to make C++ look "like math", but rather to give more
consideration to the fact that notation is essential to thought.  Which
means that dismissing changes to C++ such as foo[x,y,z] because they
are "mere syntatic sugar" is not appropriate.

*>Why should [] get any special treatment?

Perhaps because it gets special treatment is most procedural
languages and the existing C++ syntax is apalling.  The concept of a
multi-dimensional array is very widespread and used frequently (even
outside of math programming!).

*>If syntax is as important as it seems to be in your case, you should
*>consider programming in Mathematica.

Syntax is important not just for me, but for everyone.  And using
Mathematica is nice, but doesn't do anything for me or most C++
programmers because we are not writing (most of the time <g>)
math code.

*>Making C/C++ look nice for mathematics problems will benefit one
*>comparatively small segment of problems at the expense of many
*>others (including C compatability, in the case of C++).

Again, mathematics has *nothing* to do with my message other
than serving as the source of some historical examples.

I could point out that I would like to see additional operators
available in C++ as well.  For example, infix ++ has been used
in the literature as a catenation operator.  And infix >+ has been
used in the literature as a list catenation operator.  Basically,
I want the ability to define my own operators as an extension
to the language -- including precedence.

However, I don't really expect to get that.  But it *is* reasonable
to request the standards committee to reconsider their position
on "mere syntatic sugar" for things like foo[x,y,z].  This is a very
minor change to the language and while it might break some
existing C code, it won't break much and a required warning
message could ensure that the code wouldn't be broken silently.
On the other hand, the ability to use a nice syntax for multi-
dimensional arrays would improve the readability (and probably
writability) of a lot of code -- and *not* just math code.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

mfinney@inmind.com wrote in article <58thrt$gq8@mujibur.inmind.com>...
>
> You seem to have entirely missed the thrust of my message.  The
> idea is *not* to make C++ look "like math", but rather to give more
> consideration to the fact that notation is essential to thought.  Which
> means that dismissing changes to C++ such as foo[x,y,z] because they
> are "mere syntatic sugar" is not appropriate.

I think you're greatly overestimating the value of foo[x, y, z] as a
notational improvement over foo[x][y][z]. Visually, they're hardly
different at all. Consider instead (in Perl):

 open(FILE, file) or die;
 if (!open(FILE, file)) { die; }

The first version says, "do something important (and if it doesn't succeed,
fail)." The second version says, "if some function returns 'false' then do
some operation." I think it's clear that the former is a significant
notational improvement. It emphasizes the 'real' operation (and that it
must succeed), whereas the latter buries the real operation in a
conditional.

On the other hand, foo[x, y, z] looks about the same as the current C++
syntax, takes up the same amount of space, doesn't emphasize anything
different, and conflicts with existing syntax. That's the worst kind of
syntactic sugar: not only does it offer no _significant_ improvement, but
it breaks existing code.

The difference between C++ and, say, BASIC, is that C++ uses ][ as the
separator and BASIC uses a comma. BASIC requires "THEN" after the
conditional in an "IF" statement; C++ surrounds the conditional with
parentheses. This is a simple one-to-one mapping between tokens; there's no
real mental difference other than spelling. Asking for "foo[x, y, z]" is
just as silly as asking for "if x then foo". Neither one gives you anything
new or more powerful.

There's nothing wrong with dismissing syntactic sugar out of hand; if it
really improves a language's expressiveness, then it's not really sugar. I
just don't see how changing ][s to commas improves the expressiveness of
C++ at all. If you want commas, define operator() instead of operator[].
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~bradds
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <9612180510.AA29113@dwrsun4>, bradds@concentric.net (Bradd W. Szonye) writes:
|> I think you're greatly overestimating the value of foo[x, y, z] as a
|> notational improvement over foo[x][y][z]. Visually, they're hardly
|> different at all. Consider instead (in Perl):
|>
|>  open(FILE, file) or die;
|>  if (!open(FILE, file)) { die; }
|>
|> The first version says, "do something important (and if it doesn't succeed,
|> fail)." The second version says, "if some function returns 'false' then do
|> some operation." I think it's clear that the former is a significant
|> notational improvement. It emphasizes the 'real' operation (and that it
|> must succeed), whereas the latter buries the real operation in a
|> conditional.

I agree with the rest of your posting but disagree with the above.  I
read the second statement as
  "If the file fails to open, die"
which seems just as clear to me as
  "Open the file, or die"

Actually, it seems more clear since we can get into problems of what
does 'or' mean anyway:  boolean math OR, English "either one will do",
or the above Perlism of being a hidden conditional
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com
  Home page:  http://members.aol.com/BillSeurer


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

...
X-Newsreader: NN version 6.5.0 #9 (NOV)

> open(FILE, file) or die;
> if (!open(FILE, file)) { die; }

>The first version says, "do something important (and if it doesn't succeed,
>fail)." The second version says, "if some function returns 'false' then do
>some operation." I think it's clear that the former is a significant
>notational improvement. It emphasizes the 'real' operation (and that it
>must succeed), whereas the latter buries the real operation in a
>conditional.

Of course in c++ (or c for that manner), you could write the stament
as:

open(FILE, file) || die();  // C++ is not Pascal
--
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, MSSG MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 630 840 3942      Deparment Fax: 1 630 840 3785


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <9612180510.AA29113@dwrsun4>, bradds@concentric.net (Bradd W. Szonye) writes:
>I think you're greatly overestimating the value of foo[x, y, z] as a
>notational improvement over foo[x][y][z]. Visually, they're hardly
>different at all.

I consider there to be a major difference visually between [][][]
and [,,].  And a major difference in readability.

>On the other hand, foo[x, y, z] looks about the same as the current C++
>syntax, takes up the same amount of space, doesn't emphasize anything
>different, and conflicts with existing syntax.

It takes up substantially more space when using non-proportional fonts
and in any font, it takes substantially more "non-white" space.  Simply
put, "][" is *much* larger than ", " visually.  And much harder to read.

>it breaks existing code.

That can be handled by a compulsory compiler generated warning
message.  The code likely to be broken is fairly rare -- there are
*no* occurrances in any of the code that I have worked on in the
last 12 years.

>there's no real mental difference other than spelling.

Clearly everyone doesn't think that is the case.  And for user-defined
operators, it can mean an improvement in performance because of
the reduction of the number of "layers" that [][][] has to go through
compared to [,,].

>There's nothing wrong with dismissing syntactic sugar out of hand; if it
>really improves a language's expressiveness, then it's not really sugar.

If it improves readability, it is worthwhile.  And this falls into that
category.  At least in my opinion.

>If you want commas, define operator() instead of operator[].

The problem is that () has a different meaning in C/C++ than []
and so the programmer's expectations are violated.  And that
leads to bugs.




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Sachs <b91926@fsui02.fnal.gov> wrote in article
<599ncc$ptc@fsui02.fnal.gov>...
> [perl:]
> > open(FILE, file) or die;
> > if (!open(FILE, file)) { die; }
>
> Of course in c++ (or c for that manner), you could write the stament
> as:
>
> open(FILE, file) || die();  // C++ is not Pascal

Actually, that's the way it's done in Perl prior to version 5, methinks.

The only tricky part being return-code conventions. The Perl code is
reliable because anything that can fail in Perl returns the 'undefined'
value. Some C++ functions return 'true=success' and others 'true=error'.
It's one reason for standardizing on 'false=error', at least in your own
code.

And I do consider this a "superior" notation, in that it emphasizes the
"normal" course of events. In the same way that exception handling is
superior notation in that it segregates the exceptional code after the
normal course of events.
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~bradds


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

<mfinney@inmind.com> wrote:
>In <58qdek$7vs@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu
>(David A. Cuthbert) writes:
>
>*><mfinney@inmind.com> wrote:
>*>>People too often dismiss syntax as "mere syntax" or "syntatic sugar".
>*>[...]
>*>>So, when someone suggests that being able to write foo[x,y,z], I
>*>>think that too many people dismiss this too quickly as mere "syntatic
>*>>sugar".  Yes, you *could* use any of the forms that you gave
>*>>above, but with [] meaning "array subscript" in the remainder of
>*>>the language, only foo[x,y,z] makes any kind of real sense.  The
>*>>next best alternative was foo[x][y][z] which is appalling hard to
>*>>read.  And the reason that so many people keep suggesting the
>*>>enhancement.
>*>
>*>If you're expecting C++ to look a lot like math, you're expecting way
>*>too much out of the language.
>
>You seem to have entirely missed the thrust of my message.

I don't think so.  Read on.

>Perhaps because it gets special treatment is most procedural
>languages and the existing C++ syntax is apalling.  The concept of a
>multi-dimensional array is very widespread and used frequently (even
>outside of math programming!).

But this is borrowed from mathematics.  IMHO, it is -- fundamentally
-- a mathematical concept.

A multi-dimensional array is, fundamentally, an n-dimensional vector
space (assuming that you haven't overloaded the operators in a
horribly non-intuitive way).  I still fail to see how this isn't a
mathematics-notation problem.  (My Mathematica recommendation
obviously doesn't work for you, though :-)

>However, I don't really expect to get that.  But it *is* reasonable
>to request the standards committee to reconsider their position
>on "mere syntatic sugar" for things like foo[x,y,z].  This is a very
>minor change to the language and while it might break some
>existing C code, it won't break much and a required warning
>message could ensure that the code wouldn't be broken silently.

I don't see how to add syntax to support this (i.e., what is it
called? operator [] (int x, int y, int z)?).  Or should the compiler
translate this to [x][y][z]?

The former is too much to undertake at this point (esp. in regard to
the typing system and it promotes some bad habits -- the class
supporting operator [] (int, int, int) has to be aware of its atomic
representation).  The latter might make a good compiler extension,
though.  I'd rather forego [,,] in favor of a final C++ standard.

>On the other hand, the ability to use a nice syntax for multi-
>dimensional arrays would improve the readability (and probably
>writability) of a lot of code -- and *not* just math code.

On the whole, I have to agree that the [,,] operator is very useful.
However, I don't see a good way to integrate this into C++.
--
David A. Cuthbert    Graduate Student, Electrical and Computer Engineering
dac2+@andrew.cmu.edu                            Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <59cvaa$9j1@gap.cco.caltech.edu>, dacut@ugcs.caltech.edu (David A.
Cuthbert) writes:
>>Perhaps because it gets special treatment is most procedural
>>languages and the existing C++ syntax is apalling.  The concept of a
>>multi-dimensional array is very widespread and used frequently (even
>>outside of math programming!).
>
>But this is borrowed from mathematics.  IMHO, it is -- fundamentally
>-- a mathematical concept.

In that sense, so are single dimensional arrays and most concepts
in a procedural language.  Certainly arithmetic and logical operators
are mathematical at their root.  Programming and mathematics are
linked very closely.  However, making multi-dimensional arrays
available does *not* mean that we would be adopting something
purely for mathematical usage.

>A multi-dimensional array is, fundamentally, an n-dimensional vector
>space (assuming that you haven't overloaded the operators in a
>horribly non-intuitive way).

Or it can be considered to be a map from a cross product into a
set.  After all, the elements may or may not be in a number field.

And strictly speaking, even when numeric, when the subscripts
are integral values they are not in a field because they may
have zero divisors (in an 8-bit 2's complement ring, 0x10 * 0x10 = 0x00
and so 0x10 is a zero divisor).  However, that is quibbling.

>I still fail to see how this isn't a mathematics-notation problem.

It isn't a mathematics notation problem any more than single
dimension arrays or arithmetic is a mathematics notation problem.
To some degree it is.  But not because its usage is solely for
mathematics programming.  Only in the sense that programming
languages and mathematics are very tightly linked.

>I don't see how to add syntax to support this (i.e., what is it
>called? operator [] (int x, int y, int z)?).  Or should the compiler
>translate this to [x][y][z]?

>On the whole, I have to agree that the [,,] operator is very useful.
>However, I don't see a good way to integrate this into C++.

I think that it can be done in just a few paragraphs.  This is poorly worded,
but for example...

=====================

   1. If a qualified name requires multiple subscript operators, the
operators on the left can be propagated to the right.  However, a subscript
cannot be propagated to the right and be replaced in turn by one which was
propagated from the left.  Thus...

   abc[1].def[3].xyz[5]

can be written as...

   abc[1].def[3].xyz[5]
   abc[1].def.xyz[3,5]
   abc.def[1,3].xyz[5]
   abc.def.xyz[1,3,5]

but not as...

   abc.def[1].xyz[3.5]

   2. Multiple subscripts on a single name can be combined.  So...

   abc[1][3][5]

can be written as any one of...

   abc[1][3][5]
   abc[1][3,5]
   abc[1,3][5]
   abc[1,3,5]

This propagation of subscripts does not affect the semantics of the qualified
expression in any way.  It is a mere syntatical convenience.

   3. The user may define operator[]() with any number of parameters of any
type in the same manner as operator()().

   4. When a multiple subscript [] operator, for either of the above rules,
is applied, a warning message must be generated by the compiler.  The
compiler may have an option to disable the warning, but the warning message
must be present by default.  The warning message must indicate that such a
multiple subscript has been applied and that existing code which uses the ,
operator may not function correctly.

   5. If a multiple subscript [] operator is detected and there is no
matching user operator and it cannot be considered to have been propagated
from the left, then an error message must be generated.  The expression may
not default to the action of the , operator since that would silently change
the semantics by simply defining a user operator.

=====================

Note that there is no requirement for any changes in data declarations.
Native support (beyond existing C/C++) is not required for multi-dimensional
arrays.  No new forms of new and delete are required.  In other words, only
minor syntatical changes are required for propagating subscripts to the right
and only a minor extension is required to allow recognition of multiple
subscript user operators.  But, I believe that it gives us everything that we n
eed.
Better syntax and the ability (for example) to define operator[](int, int, int)
.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

bradds@concentric.net (Bradd W. Szonye) writes:

|>  David Sachs <b91926@fsui02.fnal.gov> wrote in article
    [...]
|>  > open(FILE, file) || die();  // C++ is not Pascal

    [...]
|>  And I do consider this a "superior" notation, in that it emphasizes the
|>  "normal" course of events. In the same way that exception handling is
|>  superior notation in that it segregates the exceptional code after the
|>  normal course of events.

I agree with the idea of emphisizing "normal" events.  What I do
question, however, is the idea that verifying return status is not
normal (in programming), or even that not being able to open a file is
somehow "not normal".  Thus, I would write this:

    FILE = open( file ) ;
    if ( ! FILE.isOpen() )
     die() ;

Since two very separate actions are involved (trying to open the file,
and checking its return status), I would prefer two very separate
statements.

More generally, in C++, in cases where failure would not be considered
normal (say, createTempFile), I would just write the function, and let
exceptions do their job.  (Unless special actions are taken, exceptions
cause an abnormal program termination.  Which is, IMHO, an excellent
default, and probably what die() does.)

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I looked to the discussion about multi-index operator[] several days
ago and as it seems to me the main bad thing with it is an ability to
break an existing code. But this can be fixed very easy by changing
the index separator from ',' to ';' and  write a[i; j]...


--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Igor Boukanov wrote:
>
> I looked to the discussion about multi-index operator[] several days
> ago and as it seems to me the main bad thing with it is an ability to
> break an existing code. But this can be fixed very easy by changing
> the index separator from ',' to ';' and  write a[i; j]...

I don't really understand this. People are too obsessed with syntax,
which is what you see. The semantics for all of the following can easily
be made the same, with appropriate functions/language changes:

    foo.get( 10, 20 );

    get( foo, 10, 20 );

    foo [10] [20];

    foo( 10, 20 );

    foo [10,20];

They can all resolve to the same thing. What is wrong with defining the
operator () to accept two parameters, as in the second line (which the
language currently allows)?

--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Chelly Green (chelly@eden.com) wrote:

: I don't really understand this. People are too obsessed with syntax,
: which is what you see. The semantics for all of the following can easily
: be made the same, with appropriate functions/language changes:

:     foo.get( 10, 20 );

:     get( foo, 10, 20 );

:     foo [10] [20];

:     foo( 10, 20 );

:     foo [10,20];

: They can all resolve to the same thing. What is wrong with defining the
: operator () to accept two parameters, as in the second line (which the
: language currently allows)?

It's fine, but it messes up some (template ?) functions which expect
the [][] syntax.  I think what is desired is some way to write
functions like this:

int Identity_matrix::operator[] (unsigned r, unsigned c) const
{
   if( r==c ) return 1;
   else return 0;
}

With the current operator[], this function requires an intermediate
type, say Identity_matrix_row, which exists only as a "helper class"
for the indexing operation.

Personally, I have no problem with such intermediate classes.  In
fact, purely random access to a matrix or 2D array is seldom what is
needed anyway.  Accesses are usually done in rowwise or columnwise
order, so the "helper class" is a good way to factor some repeated
computation out of the loop.

Brad

--
| Brad Stuart      brad@cfar.umd.edu
| Center for Automation Research
| University of Maryland, College Park
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]