Two Dimensional Array Template

[Kevin Hall]

Let's see if we disagree on any of these statements:

a) in C and in C++ matricies have been traditionally supported using
[][] (array of array) syntax. Hence there is a non-trivial body of
code and knowledge that is using [][] as opposed to (,).

No. In C, matrices have been traditionally supported using something
other than [][] -- at least for 'serious' numerical linear algebra
applications. Take a look at CLAPACK, the C interface for BLAS, or any
C implementation for sparse matrices.

- Kevin Hall

 

[Beliavsky]

Let's see if we disagree on any of these statements:

a) in C and in C++ matricies have been traditionally supported using
[][] (array of array) syntax. Hence there is a non-trivial body of
code and knowledge that is using [][] as opposed to (,).

I disagree. [][] is used extensively in C, but in C++ I believe that
most code involving matrices uses some sort of matrix class.

I have never seen production code use (,) for array indexing.

I have written much production code using (,) for array indexing (you
won't see it however, as it is closed-source and owned by the various
companies I worked for :/).

[snip]

I think you severely underestimate the familiarity programmers have with
[][] and the foreign nature of (,).

Not so sure about that... one class of programmers for whom (,) will be
second nature are scientific/mathematical (and in particular
[ex-]Fortran) programmers. In mathematics an array/matrix is not
generally perceived as a "vector-of-vectors" (except when it is...) and
the (,) notation sits fine with me (okay, so I *am* an ex-Fortran
programmer )

It's not just Fortran that has a good syntax for multidimensional
arrays. S (the language of S-Plus and R), Matlab, Python/Numpy, and
Visual Basic also use commas to delimit the dimensions of an array,
even when they use [] rather than () to enclose the subscripts.

a[j][k] is awkward compared to a[i,j,k] or a(i,j,k) IMO.

 

[Gianni Mariani]

I think you severely underestimate the familiarity programmers have with
[][] and the foreign nature of (,).

Not so sure about that... one class of programmers for whom (,) will be
second nature are scientific/mathematical (and in particular
[ex-]Fortran) programmers. In mathematics an array/matrix is not
generally perceived as a "vector-of-vectors" (except when it is...) and
the (,) notation sits fine with me (okay, so I *am* an ex-Fortran
programmer )

Personally I'm comfortable with either notation and concur with Daniel T.
that the only legitimate reason - albeit possibly a significant one - for
using the [][] syntax is legacy code support. So notwithstanding your
demonstration that the two approaches may be made functionally equivalent
via proxy classes, I'll go with the simpler implementation and (to me)
marginally preferable syntax of (,).

[snip]

.... snip

CLEARLY this argument is a question about syntax preference as you
demonstrated in the last two paragraphs by yourself, this is not a
technical argument about the C++ standard. IMHO, this news-group is not
the place to be making it an agenda on preferences. In other words,
sure, knock yourself out, use (,) for yourself, however keep the fallous
arguments that (,) has significant technical superiority over [][] out
of the discussion.

It is clearly the intention of the language designers that
[][] be used to access arrays

Which language? C?

C++ actually. As I mentioned, operator() is termed a functor and
operator[] is termed a subscript operator.

The FAQ is about the C++ standard and titled:

"[13.10] How do I create a subscript operator for a Matrix class?"

Clearly it does nothing of the kind since "subscript operator" is a C++
term for operator[]. In goes onto expressing an unsubstantiated syntax
preference and then making clearly false statements about the
superiority of (,) over [][].

>

.... snip

 

[Gianni Mariani]

The (,) syntax is usually called a "functor", not a "subscript"
operator. It is clearly the intention of the language designers that
[][] be used to access arrays and (,) used to call a functor. It
appears strange to me why you would ever want to use a functor when a
subscript operator is clearly intended for it's purpose.

Well, if you want to go there...basing arguments of design on what the
language designers intended...then forcing [][] on a class has no place
in any code since if the language designers had intended a class to
override [][] they would have provided the means to do so.

The language designers have provided a means to override [][], it has
been demonstrated earlier in this thread and is described in 13.12 of
the FAQ.

Needlessly changing a body of code using [][] to (,) is far more
complex. It's also not exactly a complex concept.
Again, your only argument that holds any water involves legacy code and
the FAQ has already excepted that case.

Why would I ever want to build a body of code that would exclude the
largest set of customers ? Legacy code using [][] syntax is here for a
very very long time.

Only so long as it is not changed. I work on legacy code every
day...some of the nastiest stuff ever written at times. It is rather
easy work, though boring, to change function call signatures and go
from [] to f(). I know this because I do it every day. So unless you
are selling a library that has a bunch of legacy code based on it you
don't need to worry about it...and as you showed, you can always
implement the deprecated interface for those that do if you are in such
a situation or if you don't want to change everything immediately.

We're loosing sight of the argument here. Sure, knock yourself out,
change your code to use (,) vs [][]. I certainly would be far more
cautious of changing code like that.

The use of (,) over [][] is simply a preference. The C++ standard never
mentions (,) as a subscript operator. This news group is about the C++
standard. As a preference, it should remain at most a suggestion, and
not run into a fallous diatribe over the merits of (,) over [][]. That
is the argument we have here.

No, when dealing with legacy code the issue of syntax is a minor one.

That is again an opinion. I personally approach wholesale changes like
that you describe with more caution. If I can make the change in the
library (in one place), then I would need a really good reason to start
changing large bodies of code. Simple syntactic preference is not a
good reason IMHO.

There really should be a very solid reason to

deviate. All the reasons given so far to use (,) in preference to [][]
hold no water IMHO.

(,) is easier to implement and lowers the complication of the code.

This one is clearly debunked. It takes 20 lines of code which is IMHO a
very low threshold.

There is no need for a special row proxy when you change from the row
major form or to provide safety. It is also miles better than the most
common implementation of [][] though not a whole deal greater than the
best...it's just less complex and therefore the better alternative. IE
keep it as simple as you can but no simpler.

Again the simplicity argument is in the eye of the beholder. I can't
argue about what you feel but I can say I have a vastly different
opinion of the merits of simplicity and where and when it should be
applied. This line of argument ends in the "Mariani complexity
proposition".

The Mariani simplicity/complexity proposition: There exists a minimum
complexity when modeling multiple interactive systems.

Lemma 1. When modelling interactions between multiple systems, there
exists a minimum level of complexity of the interfaces where the
overall complexity of the entire system is also minimal.

In other words, if you make your interfaces too simple, your overall
solution is more complex.

This again would lead to a conclusion about personal preferences.

More to the point. You shouldn't be implementing a "2d array". You
should be looking for a better abstraction. Once you have that better
abstraction there is no need, nor desire, to advertize that it is a 2d
array. I think the fact that there is no 2d array in the standard, nor
does there seem to be one comming in the forseable future, is quite
telling.

Sure, go for it. Regardless, there is a huge body of code that says
differently. Again this boils down to syntactic preference, not a
technical argument of the deficiencies of [][].

Your insistance on implementing a basic function as a complex set of
operator overloads reminds me of the subscript operator implemented in
some of the legacy code I work on. Implemented [] for a list that
returns the object with the serial id supplied...it's of course linear.
Then base mass "legacy" code on it in a bunch of for loops. Took me
about 4 hours to pull that member out and change all the [] calls to
functional equivilants. Time well spent IMHO...bad design is bad
design and we shouldn't stick to it just in the name of "legacy" unless
we absolutely have to.

If I was your supervisor I would have asked you to revert your change
unless you had a very good technical reason. All you have stated was a
technical preference.

At any rate, like I said...unless you are in the situation of dealing
with legacy code there is no need to worry about it. So why go to all
the trouble of forcing the [][] issue?

I think I am clearly on the side of C++ in that [][] has been used far
more than (,) and is the default syntax. You need to make an argument to
change it from [][] which is substantiated by more than just personal
preferences.

 

[Gianni Mariani]

Let's see if we disagree on any of these statements:

a) in C and in C++ matricies have been traditionally supported using
[][] (array of array) syntax. Hence there is a non-trivial body of
code and knowledge that is using [][] as opposed to (,).

No. In C, matrices have been traditionally supported using something
other than [][] -- at least for 'serious' numerical linear algebra
applications. Take a look at CLAPACK, the C interface for BLAS, or any
C implementation for sparse matrices.

I have seen *alot* of gl and OpenGL code that uses [][].

 

[Noah Roberts]

The (,) syntax is usually called a "functor", not a "subscript"
operator. It is clearly the intention of the language designers that
[][] be used to access arrays and (,) used to call a functor. It
appears strange to me why you would ever want to use a functor when a
subscript operator is clearly intended for it's purpose.

Well, if you want to go there...basing arguments of design on what the
language designers intended...then forcing [][] on a class has no place
in any code since if the language designers had intended a class to
override [][] they would have provided the means to do so.

The language designers have provided a means to override [][], it has
been demonstrated earlier in this thread and is described in 13.12 of
the FAQ.

No, that is a way to override [] in two classes and use function
chaining to *mimic* an [][] operator.

The use of (,) over [][] is simply a preference. The C++ standard never
mentions (,) as a subscript operator. This news group is about the C++
standard. As a preference, it should remain at most a suggestion, and
not run into a fallous diatribe over the merits of (,) over [][]. That
is the argument we have here.

Nor does the standard mention multi-dimensional arrays or [][]. So, if
we have to stick to the *standard* to get an opinion about which way to
go we have to say that there is just no such thing and leave it at
that.

However, the standard DOES provide tools to implement functional calls
and to override a single subscript operator.

That is again an opinion. I personally approach wholesale changes like
that you describe with more caution. If I can make the change in the
library (in one place), then I would need a really good reason to start
changing large bodies of code. Simple syntactic preference is not a
good reason IMHO.

If there is suddenly a need for a 2d array abstraction then there is
obviously a need for a change.

There really should be a very solid reason to

deviate. All the reasons given so far to use (,) in preference to [][]
hold no water IMHO.

(,) is easier to implement and lowers the complication of the code.

This one is clearly debunked. It takes 20 lines of code which is IMHO a
very low threshold.

Even one line of unnecissary complication is unnecissary complication.

Sure, go for it. Regardless, there is a huge body of code that says
differently.

Not where I'm sitting. I don't care what everyone else's huge body of
code has in it. Frankly, if the whole damn world used [][] for their
matrix abstractions, which it doesn't, it wouldn't have any bearing on
what I choose to use in mine. Nor should you let what someone else is
doing keep you from doing something better unless interaction is a
necessity. I certainly have no need to interact with the whole world
on matrix abstractions.

Your insistance on implementing a basic function as a complex set of
operator overloads reminds me of the subscript operator implemented in
some of the legacy code I work on. Implemented [] for a list that
returns the object with the serial id supplied...it's of course linear.
Then base mass "legacy" code on it in a bunch of for loops. Took me
about 4 hours to pull that member out and change all the [] calls to
functional equivilants. Time well spent IMHO...bad design is bad
design and we shouldn't stick to it just in the name of "legacy" unless
we absolutely have to.

If I was your supervisor I would have asked you to revert your change
unless you had a very good technical reason. All you have stated was a
technical preference.

How about not being able to use any other container for a "technical"
preference?

You seem overly concerned with change. I would suggest reading some
books on refactoring and possibly "Working effectively with legacy
code." Such syntatical changes are quite easy to do while being 100%
certain no behavioral change occured.

Let's just leave it as it's a damn good thing you're not my supervisor.
I hate working under micro-managers.

At any rate, like I said...unless you are in the situation of dealing
with legacy code there is no need to worry about it. So why go to all
the trouble of forcing the [][] issue?

I think I am clearly on the side of C++ in that [][] has been used far
more than (,) and is the default syntax. You need to make an argument to
change it from [][] which is substantiated by more than just personal
preferences.

All you keep saying...and you keep saying it as if it will make it
true...is that your side is stronger and therefor should be the
default. You have yet to show it in any way.

Your "legacy code" argument assumes so many illegitamate details that
are likely not even true in most cases. You not only have to have this
huge code base that uses C style arrays instead of a true abstraction
but it has to be outside your own control or so rigid that it can't
handle the addition of a true abstraction to the mix. Granted...there
are situations in which that is true but they are quite rare.

 

[Gianni Mariani]

3. Legacy code can make use of modern templates using the [][] syntax
while converting legacy code to (,) would need major code surgery.

I'd call it rather minor surgery. Any time there is a call to [][]
change to (,)...it's easy.

Making this kind of surgery for a personal preference of (,) over [][]
is IMHO not a good enough reason.

4. array2D[a] is syntactic sugar for a row reference and can be used to
optimize accesses.

Syntatic sugar yes....optimize accesses? How? Frankly it's no
different at all....assuming the compiler is able to do some basic, and
some less basic, optimizations.

operator[] returns a row reference which can be used multiple times and
computation (e.g. looking up a row in a sparse matrix etc) can be
eliminated if it is used multiple times. These kinds of operations may
or may not be optimizable, but there certainly is scope where it can.

 

[Daniel T.]

Having shown what a proxy class might look like, you will see
that all the arguments in the FAQ (yes - all of them) supporting
(,) have no supportable rationale at all.

I disagree. The fact that you used proxy classes to convert [][]
into (,) shows that all of the arguments in the FAQ are right on
the mark. Hence the reason you chose to use (,) "under the covers".

You misunderstand my intention for writing that class. I made that
proxy class to make a point that anything you can do with (,) you
can do with [][]. That was it's only purpose.

What you successfully demonstrated, regardless of your intention, was
that in order for a class that uses [][] syntax to be as flexable as a
class that uses (,), the former must convert the [][] into (,).

Remember, I asked you to produce a class that could be implemented using
any of row major, column major, and sparse arrays. What you produced was
identical to the solution presented in the FAQ, so I'm not sure what
your beef is at this point, other than the legacy code issue.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

What you successfully demonstrated, regardless of your intention, was
that in order for a class that uses [][] syntax to be as flexable as a
class that uses (,), the former must convert the [][] into (,).

Logic fallacy. He demonstrated that exists at least one implementation that
does, not that all implementations must do.

 

[Noah Roberts]

Having shown what a proxy class might look like, you will see
that all the arguments in the FAQ (yes - all of them) supporting
(,) have no supportable rationale at all.

I disagree. The fact that you used proxy classes to convert [][]
into (,) shows that all of the arguments in the FAQ are right on
the mark. Hence the reason you chose to use (,) "under the covers".

You misunderstand my intention for writing that class. I made that
proxy class to make a point that anything you can do with (,) you
can do with [][]. That was it's only purpose.

What you successfully demonstrated, regardless of your intention, was
that in order for a class that uses [][] syntax to be as flexable as a
class that uses (,), the former must convert the [][] into (,).

Well no, you could also implement it with a complex maze of highly
coupled classes so that the proxy can interact directly with the
internal memory of the main array class. Of course this means you are
writing a different proxy for each implementation instead of one that
can work with any...hense the word "coupled"...but at least you don't
have to have a function interface.

 

[Gianni Mariani]

Gianni Mariani wrote: ....
No, that is a way to override [] in two classes and use function
chaining to *mimic* an [][] operator.

And the distinction matters in what sense ?

The use of (,) over [][] is simply a preference. The C++ standard never
mentions (,) as a subscript operator. This news group is about the C++
standard. As a preference, it should remain at most a suggestion, and
not run into a fallous diatribe over the merits of (,) over [][]. That
is the argument we have here.

Nor does the standard mention multi-dimensional arrays or [][]. So, if
we have to stick to the *standard* to get an opinion about which way to
go we have to say that there is just no such thing and leave it at
that.

However, the standard DOES provide tools to implement functional calls
and to override a single subscript operator.

Let's see:

double matrix[4][4];

Are you saying that the code requires some kind of extra "implementation" ?

That's clearly a language supported abstraction for a matrix IMHO.


....

Even one line of unnecissary complication is unnecissary complication.

Who said it was unnecessary ?

Sure, go for it. Regardless, there is a huge body of code that says
differently.

Not where I'm sitting. I don't care what everyone else's huge body of
code has in it. Frankly, if the whole damn world used [][] for their
matrix abstractions, which it doesn't, it wouldn't have any bearing on
what I choose to use in mine. Nor should you let what someone else is
doing keep you from doing something better unless interaction is a
necessity. I certainly have no need to interact with the whole world
on matrix abstractions.

Just a sec, you make an assertion that there are "better abstractions"
and I make the point that there is a body of code that says differently
then you say you only care about your code. The point I'm making is
that the [][] abstraction is adequate and anything else is a personal
preference and your last paragraph seems to make my point. So are we
violently agreeing here or am I missing somthing ?

Your insistance on implementing a basic function as a complex set of
operator overloads reminds me of the subscript operator implemented in
some of the legacy code I work on. Implemented [] for a list that
returns the object with the serial id supplied...it's of course linear.
Then base mass "legacy" code on it in a bunch of for loops. Took me
about 4 hours to pull that member out and change all the [] calls to
functional equivilants. Time well spent IMHO...bad design is bad
design and we shouldn't stick to it just in the name of "legacy" unless
we absolutely have to.

If I was your supervisor I would have asked you to revert your change
unless you had a very good technical reason. All you have stated was a
technical preference.

How about not being able to use any other container for a "technical"
preference?

You seem overly concerned with change. I would suggest reading some
books on refactoring and possibly "Working effectively with legacy
code." Such syntatical changes are quite easy to do while being 100%
certain no behavioral change occured.

Let's just leave it as it's a damn good thing you're not my supervisor.
I hate working under micro-managers.

Let me see.

Programmer says: I wanna change the entire code base to use (,).
Supervisor: Why do you want to do that ?
Programmer: Because it's far better ?
Supervisor: Oh, really ! OK, what's so much better ?
Programmer: Because It's a better abstraction.
Supervisor: Sure, sounds great, why is it a better abstraction ?
Programmer: Ummm, because ...... um, it's a personal preference.
Supervisor: Go look at the bug/feature list and find some real bugs to
fix and get back to me.

Anything wrong here ?

At any rate, like I said...unless you are in the situation of dealing
with legacy code there is no need to worry about it. So why go to all
the trouble of forcing the [][] issue?

I think I am clearly on the side of C++ in that [][] has been used far
more than (,) and is the default syntax. You need to make an argument to
change it from [][] which is substantiated by more than just personal
preferences.

All you keep saying...and you keep saying it as if it will make it
true...is that your side is stronger and therefor should be the
default. You have yet to show it in any way.

I have:

double matrix[4][4];

....

 

[Gianni Mariani]

What you successfully demonstrated, regardless of your intention, was
that in order for a class that uses [][] syntax to be as flexable as a
class that uses (,), the former must convert the [][] into (,).

I didn't demonstrate that you "must" do anything. How could you
possibly come to that conclusion ?

What I did demonstrate is that the technical arguments made for the use
of (,) over [][] are false and that using (,) over [][] is a simple
personal preference and there are good, not compelling but good reasons
to stick to [][].

 

[Simon G Best]

C++ actually. As I mentioned, operator() is termed a functor and
operator[] is termed a subscript operator.

I've never heard operator() called a functor before (apart from in this
thread). Objects of classes that have operator() as a member, yes, I've
heard /them/ called functors, but not operator() itself. Isn't
operator() usually called the function call operator, or something like
that? A functor is a function object, and operator() ain't a function
object, or an object at all.

As for operator[] being called the subscripting operator, yes, that's
familiar. I'm not sure it expresses an intention for subscripting to
always be done with operator[], though. (Actually, I rather doubt it.)
But I do get the impression that there is a preference for operator[]
to only be used for subscripting and subscripting-like operations (for
the normal reasons of avoiding surprises). I suspect (rather strongly)
that it's called the 'subscripting operator' for historical reasons
(just as C-style subscripting of C-style arrays is in C++ for historical
reasons).

Simon

 

[Noah Roberts]

3. Legacy code can make use of modern templates using the [][] syntax
while converting legacy code to (,) would need major code surgery.

I'd call it rather minor surgery. Any time there is a call to [][]
change to (,)...it's easy.

Making this kind of surgery for a personal preference of (,) over [][]
is IMHO not a good enough reason.

Well, remaining simple in face of change is IMHO.

If you are suddenly in nead of such an abstraction but are running into
this "legacy code" issue then you are faced with what is known as
"rigidity". Rigidity IS a reason for surgery. It may not be reason
enough given the particulars of any given situation but it is
definately A reason. Seing as the surgery required is rather straight
forward, minimal, and safe the reason NOT to do it would then have to
be that much stronger.

There are situations in which change should be avoided because of
strong reasons against it. Preference of [][] over (,) is IMHO not a
good enough reason.

I also find it rather informative that you have held onto this ONE
requirement of "dealing with a huge legacy code base" as the only
reason to use [][] instead of (,). Of course, I've already given you
this many, many times. IF you have a huge code base that is so rigid
that you can't place an abstraction between it and your memory
layout..better to use [][] than force the (,) issue. So, if I find
myself in such a situation then as always I will weigh the issues and
decide if I should hack or go clean and simple. I do things I disagree
with all the time because of "legacy code" issues when under the crunch
or the change to clean is so astronomical as to be avoided.

Short of any other reason though, and you've yet to bring forth
anything of import besides the legacy issue, I lean toward the simpler
and cleaner approach.


As for your row optimization...if such an optimization is required and
shows up in a profile then it will be dealt with. There are many ways
to go about it. That is again a rather particular situation and
requirement that isn't faced most of the time and as such no reason to
add complexity to the code unless met.

As with all rules, the prefer () over [][] has its rarer counterpoints.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

I suspect (rather strongly) that it's called the 'subscripting operator'
for historical reasons

And + is called addition operator for historical reasons also, it just have
a longer history. Same for any other operator.

 

[Simon G Best]

Making this kind of surgery for a personal preference of (,) over [][]
is IMHO not a good enough reason.

Could you please stop saying "IMHO"? The H is silent.

Simon

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

There are situations in which change should be avoided because of
strong reasons against it. Preference of [][] over (,) is IMHO not a
good enough reason.

There are many situations in which change should be avoided because there
are no reasons to change. In that type of situations, usually those that
wants to change must find some reason, not just to say that there are no
compelling reasons to not to change.

 

[Noah Roberts]

double matrix[4][4];

That is what is known as primitive obsession. It is a smell often
causing rigidity. If an there is a requirement that this can no longer
meet then there is already a reason to change things.

The point is that you don't go into legacy code and change things willy
nilly. The abstraction is obviously now necissary because you're
creating it. If you used the above before and now need a real class
then there must be something governing that requirement. The fact that
this previous representation is no longer adiquate is what guides you
into reevaluating the code base that uses it.

So there it is...you HAVE a reason for change. The question is how
much do you change. Usually when making a change you want to make sure
your code is respondent to like changes in the future.

So if we go to your script methodology it might go something more like
this:

Programmer: I need a 2d array abstraction and I want it to look like a
C array of arrays.
Program lead: Why?
Programmer: I don't know. To be more OO.
Program lead: I mean what requirement are you trying to meet that you
want this abstraction?
Programmer: I just thought it would be cool.

Or maybe it went like:

Programmer: I need to represent some new matrices in column major form
now but all our matrix op code assumes C arrays of arrays which are row
major.
Program lead: hmm....we might have to reevaluate the assumptions we
make in our code and possibly provide some better abstractions.

And from there the discussion can go in many different directions.
Deciding to create a basic 2d array class that looks and acts just like
what you have already is but one of the possibilities and in my opinion
not one of the greatest alternatives.

 

[Noah Roberts]

There are situations in which change should be avoided because of
strong reasons against it. Preference of [][] over (,) is IMHO not a
good enough reason.

There are many situations in which change should be avoided because there
are no reasons to change. In that type of situations, usually those that
wants to change must find some reason, not just to say that there are no
compelling reasons to not to change.

A new abstraction is required because it is being created. The reason
for change exists. The question is if you want to continue
compatability with an abstraction that obviously isn't enough anymore
or do you want to do some minor editing and try for something a bit
better? The answer to this question will be governed by the
requirements placed on the team, the directions it wishes to head, and
the software in question.

 

[Gianni Mariani]

double matrix[4][4];

That is what is known as primitive obsession. It is a smell often
causing rigidity. If an there is a requirement that this can no longer
meet then there is already a reason to change things.

Don't confuse rigidity with pragmatism.

The point is that you don't go into legacy code and change things willy
nilly. The abstraction is obviously now necissary because you're
creating it. If you used the above before and now need a real class
then there must be something governing that requirement. The fact that
this previous representation is no longer adiquate is what guides you
into reevaluating the code base that uses it.

So there it is...you HAVE a reason for change. The question is how
much do you change. Usually when making a change you want to make sure
your code is respondent to like changes in the future.

You still have not explained why array of array syntax is any less
expressive than matrix(,). They not only seem interchangeable in a
programming sense, but also in a theoretical sense. Metaphorically
speaking, instead of taking the horse to the straw, take the straw to
the horse.

So even from a notation/object design perspective [][] is just as
expressive as (,). In some ways, I may be those with the obsession with
(,) over [][] that express rigidity.

....

And from there the discussion can go in many different directions.
Deciding to create a basic 2d array class that looks and acts just like
what you have already is but one of the possibilities and in my opinion
not one of the greatest alternatives.

Ah, if you go into a new design, you need design goals. Designs that
require significant deviation from prior practice (requiring learning
curve and wholesale code modifications) with the only motivation being
"personal preference" go down on the ordered list of design solutions or
get eliminated outright because of no practical gain.