"Seungbeom Kim" <musiphil@bawi.org> skrev i meddelandet
news:ea8tu5$3i1$1@news.Stanford.EDU...
> Carl Barron wrote:
>> A[i][j] is  (A[i])[j]    A[i] returns a Matrix::proxy and then
>> calls
>> Matrix::proxy::operator [](j) which returns a T & to the A[i][j] in
>> the
>> 'usual sense'.
>
> It works, but it is more complicated, and more tedious to write and
> maintain. We need two similar but different proxies for the const
> and
> non-const versions. And an additional pair of proxies for each extra
> dimension.
>
> And there could be performance issues: When I tested with gcc-3.3.5
> on
> i486-linux, I found that the proxy version doesn't produce as
> efficient
> a machine code as the directly-with-one-operator() version, even
> with a
> high optimize level. Fortunately both seem to produce the same
> machine
> code with gcc-4.0.2 on i486-linux, but there may still be less good
> compilers around.
>

Should we change the language to support bad compilers, or should we
demand good compilers?  :-)



Bo Persson


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> google@dalvander.com (Anders Dalvander) wrote (abridged):
>
>>Are there any suggestion for C++0X that operator[] overloads should be
>>allowed to support multiple arguments?
>
>
> How would you cope with comma expressions? This:
>
>     matrix[ 0, 1 ];
>
> is already valid syntax.
>
> -- Dave Harris, Nottingham, UK.

    That's a red herring.  Find one existing example, in any
stable/production level open source program, on Sourceforge or
any other major open source site, with a valid use of a comma
operator within square brackets.

    One example.  Put up or shut up.

    I'll pay $20 if anyone can find one.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
>    That's a red herring.  Find one existing example, in any
> stable/production level open source program, on Sourceforge or
> any other major open source site, with a valid use of a comma
> operator within square brackets.
>
>    One example.  Put up or shut up.
>
>    I'll pay $20 if anyone can find one.

Announcement: http://loki-lib.sourceforge.net is accepting new
developers. Easy money, guys!

:o)

For the record: I agree with John that the practical issue doesn't
really exist.


Andrei

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

nagle@animats.com (John Nagle) writes:
> Dave Harris wrote:
>> google@dalvander.com (Anders Dalvander) wrote (abridged):
>>
>>>Are there any suggestion for C++0X that operator[] overloads should be
>>>allowed to support multiple arguments?
>> How would you cope with comma expressions? This:
>>     matrix[ 0, 1 ];
>> is already valid syntax. -- Dave Harris, Nottingham, UK.
>
>     That was made a warning in GCC years ago:
> "Warning: left-hand operand of comma expression has no effect"
> It's always enabled.  Nobody seems to complain.
>
>     I proposed this a few years ago, and the big objection
> was that it might break existing code.  But nobody
> ever found any existing code it broke.  Bruce Baumgard at
> IBM Almaden once ran a search on an archive of all open source
> code known to IBM Almaden (he was doing database R&D
> and had a database of that) and couldn't find any stock
> C++ with a comma inside square brackets.  (It does show
> up in some Microsoft extensions, but not with the meaning
> of the C++ comma operator.)
>
>     After all, the worst case for this change on existing code is
> that you get a compile time error and have to add parentheses.
> It won't result in incorrect behavior of existing programs.
> If code breaks, it's more likely that you found an error
> where someone thought a two-dimensional array would work than
> that you found a legitimate use of the comma operator.
>
>     The appropriate standards change is to use the same syntax
> for the argument to "operator []" as is used for "operator()".

I might agree that breaking existing code that uses a comma operator
between "[" and "]" would be acceptable.  (But of course it's more
relevant whether the committee would agree.)

But the existing syntax for indexing into a multidimensional array:
    arr[x][y][z]
is already well established, and breaking code that uses that is
obviously not an option.

So, with the proposed change, both
    arr[x][y][z]
and
    arr[x,y,z]
could be legal, and perhaps subtly different semantics.  The former
could already involve one or more overloaded "[]" operators.  With the
proposed change, someone providing an abstract type that acts like a
multi-dimensional array could choose either syntax -- or even ugly
mixes like
    arr[x][y,z]
    arr[x,y][z]

If we were designing a new language, I might prefer to have arr[x,y,z]
by analogy with func(a,b,c) -- but we since we don't have the option
of getting rid of the existing arr[x][y][z] syntax, I suggest
continuing to use it.

If creating artificial intermediate types, so arr[x][y][z] invokes
multiple overloaded operators, is too much trouble, you could still
change the language to allow overloading operator[][] and
operator[][][] in addition to the existing operator[].

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> It works, but it is more complicated, and more tedious to write and
> maintain. We need two similar but different proxies for the const and
> non-const versions. And an additional pair of proxies for each extra
> dimension.
>
> And there could be performance issues: When I tested with gcc-3.3.5 on
> i486-linux, I found that the proxy version doesn't produce as efficient
> a machine code as the directly-with-one-operator() version, even with a
> high optimize level. Fortunately both seem to produce the same machine
> code with gcc-4.0.2 on i486-linux, but there may still be less good
> compilers around.
>
> Another solution (that may be applied only to the 2D matrix) is for the
> operator[](i) to return &data[columns * i] so that the second operator[]
> depends on the built-in one.
>

The 'proxy' implementation above, while getting the point across, is
clearly not the most efficient way to implement a matrix with
operator[]. Your last paragraph hints at a better way.  Though if you
want additional control (beyond what a raw pointer gives you, which is
nothing) over the behavior of the row returned by the first operator[],
then return a reference:

template <class T> struct Row {
    T data[...];
    T& operator[](int j) { return data[j]; }
};

template <class T> struct Matrix {
    Row<T> data[...];
    Row<T>& operator[](int i) { return data[i]; }
};

All the compilers I have used figure out the obvious optimization when
doing M[i][j] on an object M of this sort.

- Ethan

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Keith Thompson wrote:
> nagle@animats.com (John Nagle) writes:
>
>>Dave Harris wrote:
>>
>>>google@dalvander.com (Anders Dalvander) wrote (abridged):
>>>
>>>
>>>>Are there any suggestion for C++0X that operator[] overloads should be
>>>>allowed to support multiple arguments?

>
> But the existing syntax for indexing into a multidimensional array:
>     arr[x][y][z]
> is already well established, and breaking code that uses that is
> obviously not an option.

    Nor would it break.
>
> So, with the proposed change, both
>     arr[x][y][z]
> and
>     arr[x,y,z]
> could be legal, and perhaps subtly different semantics.  The former
> could already involve one or more overloaded "[]" operators.  With the
> proposed change, someone providing an abstract type that acts like a
> multi-dimensional array could choose either syntax -- or even ugly
> mixes like
>     arr[x][y,z]
>     arr[x,y][z]

    Only if you specifically design a class to work that way.  It won't
happen by accident.

    The main problem with trying to extend the traditional C syntax to
user-defined operators is that, for many operators, there is no natural
expression for

 arr[x]

when you need arr[x,y] to specify an element.  For example,
"arr" might be an associative array with string arguments, or a sparse array.

         value = arr["key1", "key2"];

is a reasonable and useful construct.

 value = arr["key1"]["key2"];

means we have to create some temporary object to represent arr["key1"], which
creates the usual "returning a reference to a temporary" problem, which
may mean an extra copy.

True multidimensional arrays have many uses, for non-rectangular arrays,
sparse arrays, symmetrical arrays, etc.  Packages exist to implement them,
and they usually result in syntax like

 arr(i,j) = value;

which is generally considered wierd in the C/C++ world.

    John Nagle

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Bo Persson wrote:
> "Seungbeom Kim" <musiphil@bawi.org> skrev i meddelandet
> news:ea8tu5$3i1$1@news.Stanford.EDU...
>>
>> And there could be performance issues: When I tested with gcc-3.3.5 on
>> i486-linux, I found that the proxy version doesn't produce as efficient
>> a machine code as the directly-with-one-operator() version, even with a
>> high optimize level. Fortunately both seem to produce the same machine
>> code with gcc-4.0.2 on i486-linux, but there may still be less good
>> compilers around.
>
> Should we change the language to support bad compilers, or should we
> demand good compilers?  :-)

Either, or both, up to a reasonable extent.
As long as we can get the result good enough -- correct and efficient.
They are meant to cooperate and complement each other, anyway.

In this particular case, if the compilers improve so that they can look
at codes from very high above and optimize away all the gory details,
it's "fine". We can live with that. On the other hand, if the language
is changed so that programmers don't even have to write the gory details
from the beginning to achieve the goal, it's even better.

Of course, the language cannot directly provide every possible usage
of proxies, so it's important that the language should provide good
abstraction mechanism, and that what it decides to support directly
is fundamental enough and benefits many users.

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

google@dalvander.com (Anders Dalvander) wrote (abridged):
> Are there any suggestion for C++0X that operator[] overloads should be
> allowed to support multiple arguments?

How would you cope with comma expressions? This:

    matrix[ 0, 1 ];

is already valid syntax.

-- Dave Harris, Nottingham, UK.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Anders Dalvander" <google@dalvander.com> writes:
> Are there any suggestion for C++0X that operator[] overloads should be
> allowed to support multiple arguments?
>
> template <typename T, size_t rows, size_t columns>
> class Matrix
> {
> public:
>    T operator[](size_t row, size_t column) const
>    {
>       return data[columns * row + column];
>    }
>
> private:
>    T data[rows * columns];
>    // or T data[rows, columns];
> };

So you want obj[x, y] to index into a multi-dimensional array, or
something like it, right?

One problem is that obj[x, y] is already legal.  The "," is a comma
operator, so, assuming x has no side effects, it's equivalent to
obj[y].

Making obj[x, y] illegal in the absence of your overloaded operator
probably wouldn't be a great loss; I suspect it's used incorrectly
more often than deliberately, and you can always change it to
obj[(x, y)] if you really mean it.  But standards committees are
rightly very cautious about breaking existing code.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kst-u@mib.org (Keith Thompson) wrote (abridged):
> Making obj[x, y] illegal in the absence of your overloaded operator
> probably wouldn't be a great loss; I suspect it's used incorrectly
> more often than deliberately, and you can always change it to
> obj[(x, y)] if you really mean it.  But standards committees are
> rightly very cautious about breaking existing code.

It would also create an incompatibility with plain C. Which might not
matter as much today as it used to, but I think it's still a
consideration.

-- Dave Harris, Nottingham, UK.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1153826038.312146.258780@h48g2000cwc.googlegroups.com>,
Anders Dalvander <google@dalvander.com> wrote:

> Are there any suggestion for C++0X that operator[] overloads should be
> allowed to support multiple arguments?
>
> template <typename T, size_t rows, size_t columns>
> class Matrix
> {
> public:
>    T operator[](size_t row, size_t column) const
>    {
>       return data[columns * row + column];
>    }
>
> private:
>    T data[rows * columns];
>    // or T data[rows, columns];
> };
>
  operator [] takes one argument.  Any user defined operator [] must
take one argument.  That said I'd redesign this using a proxy, to
something like below allowing the 'normal' notation A[i][j] to work.
not tested but it is the general idea.  Do as much as you can with the
left subscript store the results in an nested class and then compute
the result using the results saved and the right subscript.

template <....>
class Matrix
{
   T data[...];
   class proxy
   {
      T *data;
      int i;
   public:
      proxy(T *a,int b):data(a),i(b);
      T & operator [] (int j) const
      { return data[i + j]; }
   };
   public:
      proxy operator [] (int i) {return proxy(data,i*columns);}
};

Matrix<...>  A;

A[i][j] is  (A[i])[j]    A[i] returns a Matrix::proxy and then calls
Matrix::proxy::operator [](j) which returns a T & to the A[i][j] in the
'usual sense'.

If I see A[a,b] a red light goes up this is accessing A[b] after a is
computed.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris posted:

> google@dalvander.com (Anders Dalvander) wrote (abridged):
>> Are there any suggestion for C++0X that operator[] overloads should be
>> allowed to support multiple arguments?
>
> How would you cope with comma expressions? This:
>
>     matrix[ 0, 1 ];
>
> is already valid syntax.


Presumably the same way we have:

    FuncCall(0,1);

and:

    FuncCall( (0,1), 1 );


--

Frederick Gotham

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Anders Dalvander" <google@dalvander.com> wrote in message
news:1153826038.312146.258780@h48g2000cwc.googlegroups.com...
> Are there any suggestion for C++0X that operator[] overloads should be
> allowed to support multiple arguments?
>
> template <typename T, size_t rows, size_t columns>
> class Matrix
> {
> public:
>   T operator[](size_t row, size_t column) const
>   {
>      return data[columns * row + column];
>   }
>
> private:
>   T data[rows * columns];
>   // or T data[rows, columns];
> };
>


As other posts already indicated, it's impossible to support multiple arguments
with subscript without breaking the existing code. There are two basic methods
that people deal with that. One is using a different operator or named function,
e.g. operator (). The other, to return a proxy object for row(column), which in
turn defines operator [], so you can have equally natural syntax:
matrix[row][col].

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

How about something like this?

class MultiSubscriptArray
{
   Element operator[](int) const { ... }
   Element operator[](Index) const { ... }    // Preferred match utilises
all subscripts
};

class Index    // Collect one or more subscripts
{

    implicit Index(int) { ... }
    operator int() const { return 'last index'; }
};

Index operator,(Index,Index)
{... }

Index operator,(Index,int)
{... }

Probably can't be done without overloading operator,(int,int). But, then if
Index cast to int produces the same result as the base comma operator, may
not be too terrible. ;-)



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

fgothamNO@SPAM.com (Frederick Gotham) writes:
> Dave Harris posted:
>> google@dalvander.com (Anders Dalvander) wrote (abridged):
>>> Are there any suggestion for C++0X that operator[] overloads should be
>>> allowed to support multiple arguments?
>>
>> How would you cope with comma expressions? This:
>>
>>     matrix[ 0, 1 ];
>>
>> is already valid syntax.
>
> Presumably the same way we have:
>
>     FuncCall(0,1);
>
> and:
>
>     FuncCall( (0,1), 1 );

Presumably, yes, but the point is that it could break existing code.
Function call notation has been in the language since time immemorial,
so it doesn't raise the same issue.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Carl Barron wrote:
> In article
> <1153826038.312146.258780@h48g2000cwc.googlegroups.com>,
> Anders Dalvander <google@dalvander.com> wrote:

> > Are there any suggestion for C++0X that operator[] overloads
> > should be allowed to support multiple arguments?

> > template <typename T, size_t rows, size_t columns>
> > class Matrix
> > {
> > public:
> >    T operator[](size_t row, size_t column) const
> >    {
> >       return data[columns * row + column];
> >    }

> > private:
> >    T data[rows * columns];
> >    // or T data[rows, columns];
> > };

>   operator [] takes one argument.

And I think that's the key.  Others have pointed out the problem
with breaking existing code.  It's real, but I suspect that in
this particular case, a more or less acceptable solution could
be found.  (Not necessarily a pretty one, but an acceptable
one.)  On the other hand, both C and C++ already have a syntax
for indexing "multiple dimension arrays": [i][j][k].  If at all
possible, a solution should be found which preserves this
notation.

As it happens, of course, this solution has already been found,
and is widely used.

    [...]
> If I see A[a,b] a red light goes up this is accessing A[b]
> after a is computed.

Totally agreed.  If I see something like array[i, j], I suppose
that the author doesn't know C++, and become very suspicious of
everything he wrote.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Keith Thompson posted:

>> Presumably the same way we have:
>>
>>     FuncCall(0,1);
>>
>> and:
>>
>>     FuncCall( (0,1), 1 );
>
> Presumably, yes, but the point is that it could break existing code.
> Function call notation has been in the language since time immemorial,
> so it doesn't raise the same issue.


Perhaps programmers could be provided with a simple portable application
(which they could compile themselves for their own platform) which would
process source files looking for instances of:

    int array[ Func(), 5 ];

And transforms them into:

    int array[ (Func(),5) ];

Then the programmer can proceed to program in the knowledge that the array
syntax is just like the function call syntax (when it comes to usage of the
comma operator). Or is that just a pipe dream?

--

Frederick Gotham

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

fgothamNO@SPAM.com (Frederick Gotham) writes:
> Keith Thompson posted:
>>> Presumably the same way we have:
>>>
>>>     FuncCall(0,1);
>>>
>>> and:
>>>
>>>     FuncCall( (0,1), 1 );
>>
>> Presumably, yes, but the point is that it could break existing code.
>> Function call notation has been in the language since time immemorial,
>> so it doesn't raise the same issue.
>
> Perhaps programmers could be provided with a simple portable application
> (which they could compile themselves for their own platform) which would
> process source files looking for instances of:
>
>     int array[ Func(), 5 ];
>
> And transforms them into:
>
>     int array[ (Func(),5) ];
>
> Then the programmer can proceed to program in the knowledge that the array
> syntax is just like the function call syntax (when it comes to usage of the
> comma operator). Or is that just a pipe dream?

Yes, I think that's just a pipe dream.

(BTW, your example shows an array object declaration; we're talking
about a change to the array indexing operator.)

Writing a portable application to transform C++ source files is the
easy part.  The other 99% of the work is running it on existing source
files (once and only once!), updating them in SCCS / RCS / CVS /
Subversion / whatever source management systems, and so forth.  And
the other other 99% of the work is convincing everyone that it's worth
the effort.

If such a change were made to the language, I suspect compilers would
provide a flag to warn about affected code.  Such code should be
fairly rare; I've never seen a comma operator deliberately used in an
array indexing expression.  I suspect that changing any such code
manually would be easier than using some automated tool.  Then again,
people using such (rare) code might not bother to change it if there's
a compiler option to implement the old semantics.

Then again, the usual way to index into a 2-dimensional array in C++
is not arr[x, y], it's arr[x][y].  If you want this to invoke some
user-defined operation, I think you can *already* implement two
separate overloadings of [] and avoid all this hypothetical hassle.

As I said before, standards committes are rightly very hesitant to
break existing code; they almost certainly won't do so if an adequate
solution already exists.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Carl Barron wrote:
>   operator [] takes one argument.  Any user defined operator [] must
> take one argument.  That said I'd redesign this using a proxy, to
> something like below allowing the 'normal' notation A[i][j] to work.
> not tested but it is the general idea.  Do as much as you can with the
> left subscript store the results in an nested class and then compute
> the result using the results saved and the right subscript.
>
> template <....>
> class Matrix
> {
>    T data[...];
>    class proxy
>    {
>       T *data;
>       int i;
>    public:
>       proxy(T *a,int b):data(a),i(b);
>       T & operator [] (int j) const
>       { return data[i + j]; }
>    };
>    public:
>       proxy operator [] (int i) {return proxy(data,i*columns);}
> };
>
> Matrix<...>  A;
>
> A[i][j] is  (A[i])[j]    A[i] returns a Matrix::proxy and then calls
> Matrix::proxy::operator [](j) which returns a T & to the A[i][j] in the
> 'usual sense'.

It works, but it is more complicated, and more tedious to write and
maintain. We need two similar but different proxies for the const and
non-const versions. And an additional pair of proxies for each extra
dimension.

And there could be performance issues: When I tested with gcc-3.3.5 on
i486-linux, I found that the proxy version doesn't produce as efficient
a machine code as the directly-with-one-operator() version, even with a
high optimize level. Fortunately both seem to produce the same machine
code with gcc-4.0.2 on i486-linux, but there may still be less good
compilers around.

Another solution (that may be applied only to the 2D matrix) is for the
operator[](i) to return &data[columns * i] so that the second operator[]
depends on the built-in one.

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> google@dalvander.com (Anders Dalvander) wrote (abridged):
>
>>Are there any suggestion for C++0X that operator[] overloads should be
>>allowed to support multiple arguments?
>
>
> How would you cope with comma expressions? This:
>
>     matrix[ 0, 1 ];
>
> is already valid syntax.
>
> -- Dave Harris, Nottingham, UK.

    That was made a warning in GCC years ago:
"Warning: left-hand operand of comma expression has no effect"
It's always enabled.  Nobody seems to complain.

    I proposed this a few years ago, and the big objection
was that it might break existing code.  But nobody
ever found any existing code it broke.  Bruce Baumgard at
IBM Almaden once ran a search on an archive of all open source
code known to IBM Almaden (he was doing database R&D
and had a database of that) and couldn't find any stock
C++ with a comma inside square brackets.  (It does show
up in some Microsoft extensions, but not with the meaning
of the C++ comma operator.)

    After all, the worst case for this change on existing code is
that you get a compile time error and have to add parentheses.
It won't result in incorrect behavior of existing programs.
If code breaks, it's more likely that you found an error
where someone thought a two-dimensional array would work than
that you found a legitimate use of the comma operator.

    The appropriate standards change is to use the same syntax
for the argument to "operator []" as is used for "operator()".

    John Nagle

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Are there any suggestion for C++0X that operator[] overloads should be
allowed to support multiple arguments?

template <typename T, size_t rows, size_t columns>
class Matrix
{
public:
   T operator[](size_t row, size_t column) const
   {
      return data[columns * row + column];
   }

private:
   T data[rows * columns];
   // or T data[rows, columns];
};

Regards,
Anders

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Anders Dalvander wrote:
> Are there any suggestion for C++0X that operator[] overloads should be
> allowed to support multiple arguments?
>
> template <typename T, size_t rows, size_t columns>
> class Matrix
> {
> public:
>   T operator[](size_t row, size_t column) const
>   {
>      return data[columns * row + column];
>   }
>
> private:
>   T data[rows * columns];
>   // or T data[rows, columns];

That's a declaration, not the use of the [overloaded] subscript operator.

> };
>
> Regards,
> Anders

I personally don't think it's feasible to make such change in the language.
Besides, there is a whole host of work-arounds, starting with using the
function call operator.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]