Paul N. Hilfinger (hilfingr@tully.CS.Berkeley.EDU) wrote:
: Regarding Bruce Florman's "stupid C++ trick": Umm... Did you actually
: try filling in, compiling and using this definition?  I'd be curious
: to know which compilers it works on.  If, for example EltType is int
: and I write

:     main()
:     {
:  Matrix B;

:  B[2,1] = 3;
:  exit(0);
:     }

: I think you will find that the "," operator here resolves to the standard one,
: not to the one that operates on Index operators.

Of course B[2,1] doesn't work.  I never said that it would.  The first
operand to the "," operator must be of type Index.  So B[(Index)2,1]
would work, and B[i,j] works if i is an Index and j is anything that may
be converted to an int.

I did say that it was a stupid trick, didn't I?

--Bruce Florman

Just some thoughts to these proposed helperclasses for multidimensional
arrays (MDA) based upon the fact that it is than possible to call
only MDA[x] and not MDA[x][y] as expected. When the constructor of
the helperclass is public it will be possible to keep instances
of the helperclass while the MDA is already destroyed.

a) It may be unsave to create a instance (of the helperclass)
   that references the part of the MDA that actually implements the
   the array of dimension-1. E.g. when this one can be reallocated
   dynamically the reference/pointer becomes invalid.

b) The instance of the helperclass can reference the MDA itself
   to be able to call the MDA's element(x,y) function to get the actual
   element when the helperclass gets the y. When the MDA is destroyed
   the reference to it becomes invalid.

c) When you want to work with objects of the helperclass - to be on
   the save side - you have to copy the data of dimension-1 into it.
   For dynamically sized arrays this involves new/delete.
   I wonder if these can be optimized away.

d) To avoid copying while maintaining reference validity,
   or when it is unwanted/there is no need to work with objects of dimension-1,
   or when there simply exists no idea what these should represent,
   than the only way I see in C++ now (keeping the [..] syntax) is:
   Make the ctor of the helperclass private!
   Instances of the helperclass returned from MDA::operator[] are
   temporary values that are destructed at the ';'. When the
   ctor is private there is no way to store and use helperobjects
   beyond a point where its MDA can be destructed.
   The MDA::operator[] has than to be declared friend of the helperclass
   so that it can create instances.
   You see this gets quite complicated.


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de

In <KANZE.94Nov17161048@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>In article <pjl.784961435@graceland.att.com> pjl@graceland.att.com
>(Paul J. Lucas) writes:

>|> In <MCOOK.94Nov15123033@erawan.cognex.com> mcook@cognex.com writes:

>|> >>>>>> "pjl" == Paul J Lucas <pjl@graceland.att.com> writes:

>|> > pjl>   I've never understood "maintenance."

>|> >Hmm.  It's big of you to admit that in public.

>|> > pjl>   If it works now, it will work 1000 years from now.

>Question: how many real programs (of a significant size) do you know
>of which contain no errors (i.e.: which "work now")?

 That's called "fixing bugs."  Call it what it is.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

Paul J. Lucas (pjl@graceland.att.com) wrote:
: In <KANZE.94Nov17161048@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) writes:

: >In article <pjl.784961435@graceland.att.com> pjl@graceland.att.com
: >(Paul J. Lucas) writes:

: >|> >>>>>> "pjl" == Paul J Lucas <pjl@graceland.att.com> writes:

: >|> > pjl>   I've never understood "maintenance."

: >|> > pjl>   If it works now, it will work 1000 years from now.

: >Question: how many real programs (of a significant size) do you know
: >of which contain no errors (i.e.: which "work now")?

:  That's called "fixing bugs."  Call it what it is.

It depends on what kind of "bugs" you are talking about.  Bugs in the
requirements analysis?  Bugs in the design?  Bugs in the implementation?
If I read you right you only consider the last to be "Bugs".  In the
real world that just isn't true.

  mph
--
* Michael Hunter bagpiper@netcom.com or QUICS: mphunter

In <bagpiperCzKz7t.3ps@netcom.com> bagpiper@netcom.com (Michael Hunter) writes:

>Paul J. Lucas (pjl@graceland.att.com) wrote:
>: In <KANZE.94Nov17161048@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>: >In article <pjl.784961435@graceland.att.com> pjl@graceland.att.com
>: >(Paul J. Lucas) writes:

>: >|> >>>>>> "pjl" == Paul J Lucas <pjl@graceland.att.com> writes:

>: >|> > pjl>   I've never understood "maintenance."

>: >|> > pjl>   If it works now, it will work 1000 years from now.

>: >Question: how many real programs (of a significant size) do you know
>: >of which contain no errors (i.e.: which "work now")?

>:  That's called "fixing bugs."  Call it what it is.

>It depends on what kind of "bugs" you are talking about.  Bugs in the
>requirements analysis?  Bugs in the design?  Bugs in the implementation?
>If I read you right you only consider the last to be "Bugs".  In the
>real world that just isn't true.

 I'm in the real world, thank you very much.  The first again,
 changes the initial conditions, so your problem is now
 different.  Such changes are modifications.  Design _flaws_
 results in an enhancement.

 The term "maintenance" is entirely vacuous.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

>>>>> "kanze" == James Kanze US/ESC 60/3/141 #40763 <kanze@us-es.sel.de> writes:

 kanze> Question: how many real programs (of a significant size) do you know
 kanze> of which contain no errors (i.e.: which "work now")?

Forty-two?

Michael.

>>>>> "pjl" == Paul J Lucas <pjl@graceland.att.com> writes:

 pjl>   I've never understood "maintenance."

Hmm.  It's big of you to admit that in public.

 pjl>   If it works now, it will work 1000 years from now.

...assuming you don't ever want to tweak, twiddle, stretch, bend or fold it
within that period.

Michael.

In <cppCz8AK7.341@netcom.com> cpp@netcom.com (Robin Rowe) writes:

>I think I may not have been clear. What I want to know is:

> x=matrix[1][3]; // Legal with helper object.
> x=matrix(1,3);  // Generally more efficient.
> x=matrix[1,3];  // Illegal. Why???

 It is perfectly legal: the 1 gets evaluated and discarded; the 3
 gets evaluated and that is the result of the _comma_ expression.

  1, 2, 3, 4, 5; // perfectly legal C and C++ code

 The above is legal, but useless.  I suppose [i,j] is "illegal"
 because it is "illegal" in C and all native types in C++.
 According to the ARM: operator overloading is not a means to
 _mutate_ operators or the langauge.

 There are techniques that allow [i][j] via a helper object to be
 reasonably efficient.  The first [] can set a static index and
 return a constant, previously created, static, dummy object by
 reference; the second [] can take the stored first index and
 combine it with its index to return the desired element.  The
 dummy object is just "grease" to get this to work.  Since it's a
 static, dummy object returned by reference, no penalty is
 exacted for temporary object creation or destruction.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

In article <pjl.784961435@graceland.att.com> pjl@graceland.att.com
(Paul J. Lucas) writes:

|> In <MCOOK.94Nov15123033@erawan.cognex.com> mcook@cognex.com writes:

|> >>>>>> "pjl" == Paul J Lucas <pjl@graceland.att.com> writes:

|> > pjl>   I've never understood "maintenance."

|> >Hmm.  It's big of you to admit that in public.

|> > pjl>   If it works now, it will work 1000 years from now.

Question: how many real programs (of a significant size) do you know
of which contain no errors (i.e.: which "work now")?
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

Paul,

I'm going to have to be more careful with my words around here. What
I meant was x=matrix[1,3]; is illegal as an operator. I hadn't stopped
to consider that it is legal but pointless code. If allowing this change
to how the operator[] works doesn't make sense because multiple parameters
aren't allowed in C, why is x=map["Hello"]; allowed in C++?

The efficiency hit in using a helper class is not the helper object,
which can be a reference into a sub-part of the matrix, but is in doing
bounds checking twice on access to that same element. There is also
the added complexity of adding the helper class which can be a maintenance
issue. As I write this several ways to optimize this have come to mind.
Perhaps I should ask, can the helper class implementation be made just as
fast and elegant as the operator()(T,T) approach?

Some matrix class implementers use operator() instead of operator[]
to avoid the helper class. I wonder why operator[] can't have more
than one parameter since we are already allowed overloading the type
of the single parameter. What does this break? How hard is this to
implement for compiler writers? Is there a technical reason not do it?
I'm not campaigning for a change, just curious if more than inertia
makes things as they are.

Robin
--
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA
Rowe Technology            C++ training, consulting, and users groups.

In article <CzBDHJ.182@ucc.su.OZ.AU>, <maxtal@physics.su.OZ.AU> writes:

>  In short: maintenance is the process of adapting a
> program to meet changed conditions, be they changed requirements
> and specifications, or corrections to remove bugs that were not
> elicited in the previous environment.
>
>  Fair enough definition?


In his book on OOD Grady Booch writes something like:
- Maintenance: fixing bugs
- Evolution: adapting to changed requirements
- Conservation: going to great lengths to keep an ancient peace of
                code alive

Booch also states that what is usually called maintenance is actually
(in most cases) conservation.

Stefan

--
Stefan H. Holek
<holek@ivdemo.co.at>

                               "There is much Obi-Wan did not tell you."

Regarding Bruce Florman's "stupid C++ trick": Umm... Did you actually
try filling in, compiling and using this definition?  I'd be curious
to know which compilers it works on.  If, for example EltType is int
and I write

    main()
    {
 Matrix B;

 B[2,1] = 3;
 exit(0);
    }

I think you will find that the "," operator here resolves to the standard one,
not to the one that operates on Index operators.  The fact that the context
requires an Index2d is not used in the resolution, since this is C++, not Ada.

Gee, it sure would be nice if I were wrong about this, though!

P. Hilfinger


In article <Cz9pG7.262@indy.net>, bflorman@indy.net (Bruce A. Florman) writes:

:: Robin, try this "stupid C++ trick":
::
::  class Index2d
::  {
::  public:
::      Index2d (int row, int col) : m_row(row), m_col(col) { }
::      int Row () const { return m_row; }
::      int Col () const { return m_col; }
::  private:
::      int m_row, m_col;
::  };
::
::  class Index
::  {
::  public:
::      Index (int index) : m_index(index) { }
::      operator int () const { return m_index; }
::  private:
::      int m_index;
::  };
::
::  inline Index2d operator , (const Index &row, const Index &col)
::  {
::      return Index2d(row, col);
::  }
::
::  class Matrix
::  {
::      ...
::      EltType & operator [] (const Index2d &);
::      ...
::  };
::
::  Index i, j;
::  Matrix matrix;
::
::  ...
::  matrix[i,j] = ...whatever...
::

In article <cppCz8HCI.9K7@netcom.com> cpp@netcom.com (Robin Rowe)
writes:

|> The efficiency hit in using a helper class is not the helper object,
|> which can be a reference into a sub-part of the matrix, but is in doing
|> bounds checking twice on access to that same element.

Each bound is checked exactly once, no matter which approach you use.

|> There is also
|> the added complexity of adding the helper class which can be a maintenance
|> issue. As I write this several ways to optimize this have come to mind.
|> Perhaps I should ask, can the helper class implementation be made just as
|> fast and elegant as the operator()(T,T) approach?

In principle, if the helper class is entirely inline, it should be
possible for the compiler to generate exactly the same code as if a
single operator were used.  Although I have done no measurements, I
somehow doubt that current compilers are actually this good, however.

|> Some matrix class implementers use operator() instead of operator[]
|> to avoid the helper class. I wonder why operator[] can't have more
|> than one parameter since we are already allowed overloading the type
|> of the single parameter. What does this break?

Possibly some existing code, although probably not much.

It also breaks orthogonality, although I suppose one could argue that
this is already broken in that comma is sometimes a separator (as in a
list of function parameters), sometimes an operator.

|> How hard is this to
|> implement for compiler writers?

Probably not too difficult.  Not that the compiler writers don't have
enough to do already.

|> Is there a technical reason not do it?

There is a simple alternative, so why bother.  Given the choice,
compiler writer's time being finite, I'd rather have a few bug fixes.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In <cppCz8HCI.9K7@netcom.com> cpp@netcom.com (Robin Rowe) writes:

>I'm going to have to be more careful with my words around here.

 I answer the question asked; sorry.  It hard enough getting the
 correct answer; I shouldn't have to second guess what somebody
 may have 'meant' in their question.

>What I meant was x=matrix[1,3]; is illegal as an operator.  If allowing
>this change to how the operator[] works doesn't make sense because
>multiple parameters aren't allowed in C, why is x=map["Hello"]; allowed
>in C++?

 Because it's not changing the number of parameters.  You are
 comparing apples and oranges.

>The efficiency hit in using a helper class is not the helper object,
>which can be a reference into a sub-part of the matrix, but is in doing
>bounds checking twice on access to that same element.

 Huh?  You have to check each dimension _exactly_ once.

>There is also the added complexity of adding the helper class which can
>be a maintenance issue.

 I've never understood "maintenance."  If it works now, it will
 work 1000 years from now.

>As I write this several ways to optimize this have come to mind.  Perhaps
>I should ask, can the helper class implementation be made just as fast
>and elegant as the operator()(T,T) approach?

 I don't know, I've never tried.  I've never had any interest in
 writing a matrix class.  Why don't you try it?

>Some matrix class implementers use operator() instead of operator[] to
>avoid the helper class. I wonder why operator[] can't have more than one
>parameter since we are already allowed overloading the type of the single
>parameter.

 Apples and oranges.

>What does this break?

 It introduces an entirely new construct into an already complex
 language.  The point of operator overloading is to allow classes
 to be treated like built-in types; not to do things above and
 beyond.

 The _point_ of allowing [] to be overloaded is to mimick [] for
 built-in types.  Well, [] for built-in types doesn't do [i,j]
 the way you want; therefore, [] for classes shouldn't either.

>How hard is this to implement for compiler writers?

 Trivial, but that's not the point.  Evervybody has their
 favorite "trivial" feature they'd like to see implemented.
 Remember the good ship Vasa.

>Is there a technical reason not do it?

 It's an exception (or a wart, depending on your point of view).

>I'm not campaigning for a change, just curious if more than inertia makes
>things as they are.

 History and orthogonality are more like it.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

In article <cppCz66BA.DJ1@netcom.com> cpp@netcom.com "Robin Rowe" writes:

><< You might consider using parentheses for multiple subscripting, as
>operator() can be overloaded with any number of arguments. >>
>
>I've been wondering why multiple subscripts aren't allowed for [].
>What's the rationale?

'Cos Dennis didn't do it that way :-)

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

Paul J. Lucas (pjl@graceland.att.com) wrote:
: In <cppCz8AK7.341@netcom.com> cpp@netcom.com (Robin Rowe) writes:

: >I think I may not have been clear. What I want to know is:

: > x=matrix[1][3]; // Legal with helper object.
: > x=matrix(1,3);  // Generally more efficient.
: > x=matrix[1,3];  // Illegal. Why???

:  It is perfectly legal: the 1 gets evaluated and discarded; the 3
:  gets evaluated and that is the result of the _comma_ expression.

:   1, 2, 3, 4, 5; // perfectly legal C and C++ code
:
:  The above is legal, but useless.  I suppose [i,j] is "illegal"
:  because it is "illegal" in C and all native types in C++.
:  According to the ARM: operator overloading is not a means to
:  _mutate_ operators or the langauge.

There's nothing illegal at all about the expression   matrix[i,j]   as
long as you've declared the types properly.  ;-)

Robin, try this "stupid C++ trick":

 class Index2d
 {
 public:
     Index2d (int row, int col) : m_row(row), m_col(col) { }
     int Row () const { return m_row; }
     int Col () const { return m_col; }
 private:
     int m_row, m_col;
 };

 class Index
 {
 public:
     Index (int index) : m_index(index) { }
     operator int () const { return m_index; }
 private:
     int m_index;
 };

 inline Index2d operator , (const Index &row, const Index &col)
 {
     return Index2d(row, col);
 }

 class Matrix
 {
     ...
     EltType & operator [] (const Index2d &);
     ...
 };

 Index i, j;
 Matrix matrix;

 ...
 matrix[i,j] = ...whatever...

:  There are techniques that allow [i][j] via a helper object to be
:  reasonably efficient.  The first [] can set a static index and
:  return a constant, previously created, static, dummy object by
:  reference; the second [] can take the stored first index and
:  combine it with its index to return the desired element.  The
:  dummy object is just "grease" to get this to work.  Since it's a
:  static, dummy object returned by reference, no penalty is
:  exacted for temporary object creation or destruction.

Of course if the index subexpression to the second [] directly or
indirectly evaluates another [][] expression, you're hosed.  But at least
you didn't have to copy two ints to get there!

--Bruce Florman

In article 784782020@graceland.att.com, pjl@graceland.att.com (Paul J. Lucas) writes:
>In <cppCz8HCI.9K7@netcom.com> cpp@netcom.com (Robin Rowe) writes:
>
>
> The _point_ of allowing [] to be overloaded is to mimick [] for
> built-in types.  Well, [] for built-in types doesn't do [i,j]
> the way you want; therefore, [] for classes shouldn't either.
>
>>How hard is this to implement for compiler writers?
>
> Trivial, but that's not the point.  Evervybody has their
> favorite "trivial" feature they'd like to see implemented.
> Remember the good ship Vasa.

Beyond that, allowing comma-separated subscripts changes the langauge
in ways that break existing code. The expression
 a[e1, e2]
already has a meaning. It is equivalent (except for sequence points) to
 (e1, a[e2])

The utility of being able to write a[i,j] instead of a(i,j) or a[i][j] has to
be weighed against breaking programs which assume the current language rules.
We can argue about why anyone would write a[e1,e2], but that doesn't change
the many years of C history inherited by C++.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <cppCz8HCI.9K7@netcom.com>, Robin Rowe <cpp@netcom.com> wrote:
>Some matrix class implementers use operator() instead of operator[]
>to avoid the helper class. I wonder why operator[] can't have more
>than one parameter since we are already allowed overloading the type
>of the single parameter. What does this break? How hard is this to
>implement for compiler writers?...

Everything is easy as long as you are not the schmuck who has to implement
it.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

In article <cppCz8AK7.341@netcom.com> cpp@netcom.com "Robin Rowe" writes:

>I think I may not have been clear. What I want to know is:
>
>        x=matrix[1][3]; // Legal with helper object.
>        x=matrix(1,3);  // Generally more efficient.
>        x=matrix[1,3];  // Illegal. Why???

x = matrix[1,3] is legal, it just means x = matrix[3] in this case.
The comma operator evaluates its operands in order from left to right
discarding all the but the last result.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

In article <cppCz8AK7.341@netcom.com> cpp@netcom.com (Robin Rowe) writes:
>I think I may not have been clear. What I want to know is:
>
> x=matrix[1][3]; // Legal with helper object.
> x=matrix(1,3);  // Generally more efficient.
> x=matrix[1,3];  // Illegal. Why???

 Sigh. 1) I have proposed this _informally_ and there
 was some support for the idea.

 2) nothing will happen unless a paper is written:
 a formal proposal is needed.

 3) IF you want to be able to overload operator[] just like
 overloading operator() THEN since I'm sick of writing
 proposals

 VOLUNTEER to WORK on the proposal. A leader and some
 supporters are needed.

 I will help by providing an outline of the proposal.

 I will proof read the proposal.

 I will play devil's advocate -- which will be fun,
 because I support the proposal.

 I will ensure the proposal is submitted to the
 committee in time for the March meeting.

 I will seek opinions from committee members by
 posting drafts to the committee reflectors.

 Bjarne is the leader of the extensions group and will
 put the proposal up for a vote on priorities. His usual
 format is to pick the MOST and LEAST important items
 from the list and deal with them (so you have two chances
 of the proposal getting a hearing in the extensions group).

 IF the extensions group considers the proposal, they may
 reject it. In that case it will not even be raised before
 the committee as a whole for discussion.

 IF the extensions group is in favour of the proposal,
 Bjarne will present it for discussion.

 IF a straw vote has clear majority of ANSI/X3J16
 members in favour, AND there is no strong opposition
 from WG21 THEN a formal vote will be taken at the end
 of the week.

FYI: IMHO this proposal has merit. The operator() syntax
is well understood so there are no great technical difficulties
implementing of adopting it for []. Some small amount of
code using comma inside [] may be broken, although it is
trivial to repair by writing

 [a,b]

as

 [(a,b)]

however detection of the problem may not be completely
reliable. Quite a lot of newbies "have a go" at doing this:
its clearly expected, and many people use multi-dimensional
arrays for one reason or another.

The most challanging part of the proposal is convincing the
committee that the change is worth the effort. There is
guarranteed NO hope of that if you, the reader, are not
willing to spend time stating your desires and analysing
the consequences.

Only few hours committee time remain to work on the contents
of the proposed Standard before its scheduled publication.

Why should those hours be spent on _this_ proposal, instead
of say partial specialisations, problems with templates,
or a host of other issues that already consume all the available
efforts of a group of voluntary workers?

Few extensions not backed by the Library Working Group,
a National Body, or Bjarne Stroustrup, and perceived
as more or less "necessary" are likely to
succeed at this point in time -- and it is best to have
all three and be able to show the world will stop spinning
if the extension is not approved.

There is a strong feeling the time has come to stop adding
new features to C++. But this is a small change, its useful,
its not very important, but sometimes the extensions WG
needs a break from heavier problems.

If you are STILL prepared to work on it after reading all
that, send me an email. maxtal@suphys.physics.su.oz.au

--
        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 <pjl.784782020@graceland.att.com> pjl@graceland.att.com (Paul J. Lucas) writes:
>
>>There is also the added complexity of adding the helper class which can
>>be a maintenance issue.
>
> I've never understood "maintenance."  If it works now, it will
> work 1000 years from now.

 Paul, if I build a house in the dry summer, it stands
and shades me just fine. It "works". Suddenly, the monsoon
season hits and its starts leaking. I have to "maintain" it
because it was not built and tested in this new environment.

 Whether a system "works"  depends on its environment.
Environments change -- especially customer requirements
and other programs with which it has to interface.

 In short: maintenance is the process of adapting a
program to meet changed conditions, be they changed requirements
and specifications, or corrections to remove bugs that were not
elicited in the previous environment.

 Fair enough definition?
--
        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 <cppCz8HCI.9K7@netcom.com> cpp@netcom.com (Robin Rowe) writes:
>Some matrix class implementers use operator() instead of operator[]
>to avoid the helper class. I wonder why operator[] can't have more
>than one parameter since we are already allowed overloading the type
>of the single parameter.

 Because Bjarne did not originally specify it in the ARM
and no one has made a formal proposal to change it that has been
accepted.

>What does this break?

 That depends on the exact proposal. Should

 x[a,b]

be interpreted as

 x[(a,b)]

if x is a C type? What if it is a C++ type without an overloaded
operator []? What if there is an overloaded operator[]
that only takes one argument?

>How hard is this to
>implement for compiler writers?

 I'm not an implementor but it is probably trivial,
since operator() already exists and can have arbitrary parameters.

>Is there a technical reason not do it?

 See above. Some code will be broken. The question is
which code? All of it? Some of it? Is there a way to guarrantee
none of it? <No, I feel>

>I'm not campaigning for a change, just curious if more than inertia
>makes things as they are.

 There are technical problems because _some_ code
may be broken and political ones because that introduces
the need to discuss possible compromises. Including whether
time would better be spent on other problems.

 The C++ committee does not have a problem with inertia!
It is accused more often of changing too much too fast.
It _does_ have a serious problem with availability of resources,
however: time, money, brain power. All of these things are
required to find both technical and political solutions.

 Maybe someone should try modifying GNU C++.


--
        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

maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>         Sigh. 1) I have proposed this _informally_ and there
>         was some support for the idea.
>
>         2) nothing will happen unless a paper is written:
>         a formal proposal is needed.
>
>         3) IF you want to be able to overload operator[] just like
        [...]
>         I will play devil's advocate -- which will be fun,
>         because I support the proposal.
>
>         I will ensure the proposal is submitted to the
>         committee in time for the March meeting.

IMO there are much better things to spend effort on. Writing [] instead
of () or .element() is prettier but not really needed or even useful.

However, since you seem to be serious, allow me to make a few points:

> FYI: IMHO this proposal has merit. The operator() syntax
> is well understood so there are no great technical difficulties
> implementing of adopting it for [].

I can't quite agree. Operator() is not like operator[] because the
commas are parsed differently. You want (I think) to make [] now be
parsed the same way () is. (Well, the same way () is when it's in
function-call guise.)

See, C++ compilers don't (generally, AFAIK) take into account what
operators have been defined until very late. They just parse it down to
operators, and _only then_ if there's a class in the key position(s), go
looking for user-defined operators. It's way faster. (Pardon the
simplifications)

So if you want [a,b], then to make the parsing halfway possible the
built-in operators [a][b] change to [a,b] also.

So (I emphasize again) you are changing _all_ [a][b] to [a,b], not just
the user-defined. This is a huge change.

If you do go ahead with this, I'd favor [a][b][c]..., because at least
it's parsed that way to start with and you just have to find the right
operators, and arbitrate ambiguity.


> Some small amount of
> code using comma inside [] may be broken, although it is
> trivial to repair by writing

Well, most breakages are easy to repair -- it's discovering them that's
hard. OTOH, I feel that any code that made use of [a,b] should be
euthanised anyways.

I'll be the first to say it: The comma operator was a mistake. The only
vaguely useful thing it does is allow multiple statements inside control
structures, and that is only because the semicolon is co-opted for
a secondary use. There could have been a more orthagonal syntax for the
for loop (say, multiple parentheses), and comma could have been a "pure"
argument-seperator.

But there wasn't and it wasn't and IMO now we're stuck with it.

        Tom

PS: You are a very bright fellow and IMO you should spend your talent on
something more substantive than prettying up operator() into operator[].

--
finger me for how Tehomega is coming along (at tob@world.std.com)
Author of The Burning Tower (from TomBreton@delphi.com) (weekly in
rec.games.frp.archives)

>>>>> Tom O Breton <tob@world.std.com> writes:

> I'll be the first to say it: The comma operator was a mistake. The only
> vaguely useful thing it does is allow multiple statements inside control
> structures, and that is only because the semicolon is co-opted for
> a secondary use. There could have been a more orthagonal syntax for the
> for loop (say, multiple parentheses), and comma could have been a "pure"
> argument-seperator.

I see the comma operator as an effort to be more LISPy than purer
procedural languages like, say, Pascal.  The comma operator corresponds
directly to LISP's progn, and the ?: operator corresponds to LISP's if.

Jason

In <MCOOK.94Nov15123033@erawan.cognex.com> mcook@cognex.com writes:

>>>>>> "pjl" == Paul J Lucas <pjl@graceland.att.com> writes:

> pjl>   I've never understood "maintenance."

>Hmm.  It's big of you to admit that in public.

> pjl>   If it works now, it will work 1000 years from now.

>...assuming you don't ever want to tweak, twiddle, stretch, bend or fold it
>within that period.

 No, you're changing the initial conditions such that your
 problem is different now.  "Maintenance" is just a bad word,
 IMO.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

I think I may not have been clear. What I want to know is:

 x=matrix[1][3]; // Legal with helper object.
 x=matrix(1,3);  // Generally more efficient.
 x=matrix[1,3];  // Illegal. Why???

Robin

--
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA
Rowe Technology            C++ training, consulting, and users groups.

<< You might consider using parentheses for multiple subscripting, as
operator() can be overloaded with any number of arguments. >>

I've been wondering why multiple subscripts aren't allowed for [].
What's the rationale?

Robin

--
-----
Robin Rowe                 cpp@netcom.com  408-375-9449  Monterey, CA
Rowe Technology            C++ training, consulting, and users groups.

In <cppCz66BA.DJ1@netcom.com> cpp@netcom.com (Robin Rowe) writes:

><< You might consider using parentheses for multiple subscripting, as
>operator() can be overloaded with any number of arguments. >>

>I've been wondering why multiple subscripts aren't allowed for [].
>What's the rationale?

 Because there aren't multiple subscripts for built-in types!

  int a[10][5];
  // ...

  a[3][2] = 0; // this is _not_ a multiple subscript!

 There is no such thing as a multiple subscript in C++ or C;
 never was.  You forget what is going on.  The above is
 equivalent to:

  (a[3])[2] = 0;

 which is:

  *((*(a+3))+2) = 0;

 Brackets are syntactic sugar.  This equivalence is one of the
 beauties of C, IMO.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL