Two Dimensional Array Template

[Michael DOUBEZ]

Julián Albo a écrit :

As I said before, an array-of-array POD is not at all flexible because

But it is talking about that? I doubt that, given that in the previous
sentence it talks about the [ ] operator in general, not just about raw
arrays. Yet again, the arguments in this point in the FAQ are a confusing
mix between syntax and implementation.

It is not a mix, from my point of view, the decision tree is the following:
Pre: I have two solutions for matrix script access: 1. [][] and 2. (,)

Q1. Can I implement both ?
R1. Preferabily not, it would only confuse user (i.e. minimal interface
is preferable)

Q2. Then I have to choose one. Which one ?
R2. There are two main reason to choose (,)
a. [][] is not flexible enough for garanteed good optimisation.
b. Using [][] in a flexible manner may yield worse optimisation.
There is no hard proof (the FAQ never claimed one) but [][] is
suspicious. Therefore, it is preferable to use (,) in the general case.

It is not a mix but [][] has a tradeoff between flexibility and
potential optimisation where (,) doesn't.

You don't have to if you don't want. People that have a reason to do it will
evaluate if the risk is low enough to him. That is all the point, that
saying that it never be used is an inadequate over-generalization.

And the FAQ doesn't say differently: in general, it is good practise to
use (,) and for specific reason you can use [][] at some potential cost.

The recommandation is here to say that if you do so, then you have a
special need; if you use [][] without special need then you like danger

So the point is just to be able to call 'special' to other people's reasons?

The point is to call 'special' cases where people implement risky stuff
when they have a safe alternative (i.e. have reason not to use the
general best practice).

Perfectly fine for you, but hardly a good argument to satisfactory prove the
point for the world in general.


Do you mean that if you don't like it then nobody will use it?

No, I mean I will not add a useless interface. If accessor f() is
already implemented, there is no good reason that I can think of to
implement an additionnal accessor g() that does exactely the same thing.

Customer> What is the difference between f() and g() ?
Support> None at all.
Customer> Then which one is best to use?
Support> The one you prefer. It is the cost of liberty.

Customer Gain: 0
Customer Loss: 5 min, a phone call, 30min depression about choice in his
life
Support Gain: 0
Support Loss: Time, sense of uselessness
Compagny Gain: 0
Compagny Loss: Money from support, confused customer

The FAQ doesn't forbid but point out the choice to make.
--> [13.10] How do I create a subscript operator for a Matrix class?
--> Use operator() rather than operator[].
This does not look to me like the exposition of a choice that must be
made. Looks like an imperative.

If you have a question, I give an answer.
If you have a problem, I propose solutions.

If the proposition looks bad to some people, is criticized.

Then it is a problem, that is why the FAQ writes an explaination why (,)
is a better choice in the general case.

Yes, that is the 'Q' in 'FAQ'. Nothing new here.

So you got your answer.

Q. Which one should I choose ?
A. The (,) because it is the general best practice.

If you think you may have good reasons to use [][], the question would
have been:
Q. Considering I have constraint/functionnality X to achieve, which one
should I choose ?
A. You are right/wrong to use [][] or have the following tradeoff ...

The FAQ is not an expert system.

Personnaly, I don't see any problem or trial of coercition in the FAQ.
If you do, then one of us may have to re-evaluate his reading in order
to communicate together (if we really have to because I am done with
this thread).

Michael

 

[Gianni Mariani]

Julián Albo a écrit :

As I said before, an array-of-array POD is not at all flexible because

But it is talking about that? I doubt that, given that in the previous
sentence it talks about the [ ] operator in general, not just about raw
arrays. Yet again, the arguments in this point in the FAQ are a confusing
mix between syntax and implementation.

It is not a mix, from my point of view, the decision tree is the following:
Pre: I have two solutions for matrix script access: 1. [][] and 2. (,)

Q1. Can I implement both ?
R1. Preferabily not, it would only confuse user (i.e. minimal interface
is preferable)

Q2. Then I have to choose one. Which one ?
R2. There are two main reason to choose (,)
a. [][] is not flexible enough for garanteed good optimisation.
b. Using [][] in a flexible manner may yield worse optimisation.
There is no hard proof (the FAQ never claimed one) but [][] is
suspicious. Therefore, it is preferable to use (,) in the general case.

Suspicious ? That's a very low threshold to make such a decision with.
We have people refactoring oodles of code to use [][] based on
suspicion which is not good.

I expect better than that from an FAQ. The FAQ is cited as a source for
well answered questions not ones based on silly suspicions.

It is not a mix but [][] has a tradeoff between flexibility and
potential optimisation where (,) doesn't.

I'm one of those that errs on the wrong side of making premature
optimizations more than I care to admit, for me to decide quite firmly
that I don't perceive a danger with [][] over (,) for optimization
purposes should say somthing.

As has been said before, [][] can be used with regular POD array of
array as well as matrix classes and a matrix function template could
easily provide the basis for both regular POD types as well as matrix
classes if the class supported the [][] syntax. That's a big bonus.

The other important issue is legacy code which no-one seems to argue with.

Finally the most critical one is ambiguilty. var[][] is very easy to
identify as a subscript operation while var(,) can easily be confused as
a function call, i.e. there is no learning curve.

These are all good reasons to go with [][] vs (,). None of these are
mentioned in the FAQ and should be.

You don't have to if you don't want. People that have a reason to do
it will
evaluate if the risk is low enough to him. That is all the point, that
saying that it never be used is an inadequate over-generalization.

And the FAQ doesn't say differently: in general, it is good practise to
use (,) and for specific reason you can use [][] at some potential cost.

You make an assertion that "it is good practice to use (,)" but it is
simply based on fear of optimization performance for an unspecified
compiler and denies any of the good reasons for the alternative.

When I see performance issues with my compilers I file bugs. I've been
pleasantly surprised by the response for optimization issues by all the
vendors I have filed with.

The recommandation is here to say that if you do so, then you have a
special need; if you use [][] without special need then you like danger

So the point is just to be able to call 'special' to other people's
reasons?

The point is to call 'special' cases where people implement risky stuff
when they have a safe alternative (i.e. have reason not to use the
general best practice).

General best practice involves:

a) Not inventing new things to do old things ([][] works fine no need
for a new (,) interface).
b) Getting compiler bugs/optimizations characterized and fixed.
c) Worrying about optimization only when you really have to.

The argument for (,) fails all three of those.

No, I mean I will not add a useless interface. If accessor f() is
already implemented, there is no good reason that I can think of to
implement an additionnal accessor g() that does exactely the same thing.

Great. [][] works fine, use it then, no need to invent a non-standard
interface (,).

....

The FAQ doesn't forbid but point out the choice to make.
--> [13.10] How do I create a subscript operator for a Matrix class?
--> Use operator() rather than operator[].
This does not look to me like the exposition of a choice that must be
made. Looks like an imperative.
If you have a question, I give an answer.
If you have a problem, I propose solutions.

If the proposition looks bad to some people, is criticized.

Then it is a problem, that is why the FAQ writes an explaination why (,)
is a better choice in the general case.

There is exactly one reason that is made by the FAQ for (,) and only one
belatedly for [][]. The FAQ is not a good source of information on this
topic.

So you got your answer.

Q. Which one should I choose ?
A. The (,) because it is the general best practice.

And pigs fly.

If you think you may have good reasons to use [][], the question would
have been:
Q. Considering I have constraint/functionnality X to achieve, which one
should I choose ?
A. You are right/wrong to use [][] or have the following tradeoff ...

The FAQ is not an expert system.

Personnaly, I don't see any problem or trial of coercition in the FAQ.
If you do, then one of us may have to re-evaluate his reading in order
to communicate together (if we really have to because I am done with
this thread).

The FAQ is very light on fact. The quality of this section of the FAQ
is by far one of the lowest in the entire FAQ.

 

[Daniel T.]

Daniel T. wrote:
(a) does not talk about [][] versus (,).

So it is irrelevant to the discussion at hand.

That depends on how narrowly you define the topic of the discussion.
If you consider the veracity of the FAQ as the topic at hand, and if
you consider the rationales provided by the FAQ as claims of the
FAQ, then (a) is relevant as the FAQ creates the impression that
your life would be simpler without the proxy classes.

I think the implication of the FAQ is different. But this thread is more
about what the FAQ says, rather than what it implies. Is there anything
that it says that you disagree with?

Why/how is [][] more "useful" syntacticly than (,)?

It's not---well: asside from generic algorithms templates that could work
with, e.g., double[m][n] as well as any matrix class offering [][].

And the FAQ does make an exception for legacy code. To assert that *new
code* should use arrays of arrays is to deny FAQ 34.1.

I fail to see how this is only related to legacy code.
vector<vector<float> > is a perfect example of a 2D-array that offers
[][] but not (,). If you program generic matrix algorithms, why
would you want to exclude this data structure?

The construct in question is exactly what 13.11 argues against.
Although, I think that is a viable construct to use as a possible
implementation of a Matrix class, I wouldn't use it raw, nor advocate
its use. (Again, I accept that it may be used extensively in some legacy
code and in that case, one may be forced to support it.)

No, I agree with a point in the FAQ that I consider minor (namely that some
simple access for matrix coefficients is a nice thing to have). I disagree
with the FAQ on this issue in general as I do not think it provides a good
discussion of interface design for a matrix class.

It isn't meant to cover a "good discussion of interface design for a
matrix class."

In particular, you might disregard introducing row and column
proxies because the FAQ did not discuss them fairly.

IMO, the class would be better for it, but let's try to stick to what
the FAQ actually says rather than your impression (or mine) of what a
good matrix interface design should look like.

Of course you can write a wrapper matrix class based upon a
basic_matrix class. That is a viable design.

IMO, yet another inappropriate design.

However, it does not demonstrate that the basic_matrix class is a
well-designed matrix class. This structure is nothing but an
implementation detail of the full-fledged matrix class.

IMO, embedded proxies have no place in a full-fledged matrix class. I
believe that the design should be complete and minimal. Embedding
classes and function calls that could easily be written outside of the
Matrix proper (with no loss in performance or express-ability) makes for
a fat interface. If you care to go further down this road, we should
probably start a new thread though because it has nothing to do with
what the FAQ actually says.

The FAQ doesn't ask what a well designed, full-fledged matrix class
looks like. It only compares two methods of single element access.

The main thrust of the FAQ is how to implement single element
access (How do I create a subscript operator for a Matrix class?),
what we learn is that performance wise, "the operator() approach
is never worse than, and sometimes better than, the [][]
approach." That is something that simply cannot be said the other
way around, at least not for all possible standards conforming
compilers.

The relevance of a statement about all possible (as opposed to all
actual) compilers when it comes to performance considerations is
highly doubtfull. What matters is whether people can be expected to
run into performance problems. The optimization techniques that
prevent this are well known and widely implemented.

IMO, the relevance of such micro-optimizations in general is highly
doubtful. I'm willing to completely drop the speed issue. The FAQs in
question make reference to "performance" in a few places but are all
sufficiently equivocal as to be pointless (not incorrect, just not worth
arguing about.) It was a blind ally I should have never gone down.

 

[Daniel T.]

I agree, that using a get_element function is much more descriptive.
However, it makes it less compatible with templates using standard
syntax to access an array.

I would recommend using a descriptive get_x function over using
operator() method.

Moreover, I think a get and set function would have more flexibility,
and it's obviously less ambiguous.

Although I completely agree with you here, you are now talking pure
syntax (what should the name of the function be?)

My personal preference is "at()".

 

[Daniel T.]

Gianni Mariani a écrit :

Daniel T. wrote:
...

On Jan 3 you said, "The FAQ does state many false claims in support of
the position of using (,) over [][]." How about you state one assertion
that is in the FAQ that you think is false and let's see what happens.
Just one of the many you say exist so we don't get too distracted.

Read this post:
http://groups.google.com.au/group/comp.lang.c++/msg/c3bbd70542232ca6?dmode=s
ource&hl=en

I explained it all paragraph by paragraph. What more do you want ?

A critic of what you said:
- You said: "As you can see, the FAQ bases all the claims on the
false assumption that by using [][], you cannot implement optimizations
using (,)."
- The FAQ says: "The array-of-array solution obviously works, but
it is less flexible than the operator() approach. Specifically, there
are easy performance tuning tricks that can be done with the operator()
approach that are more difficult in the [][] approach, and therefore the
[][] approach is more likely to lead to bad performance, at least in
some cases."

Keep in mind Michael, that quote is about a particular implementation of
[][]. Read the paragraph before and after it.

 

[Simon G Best]

Wow, I think you've really misunderstood me.

Daniel T. wrote:
...

Again IMO, and according to the FAQ, calling op(,) is a better method of
accessing a single element of the array (as opposed to calling op[] and
then op[] on the result.) Now this is something that several seem to be
disagreeing with, but frankly I don't understand why.

No, I really think you've got that wrong. Just because there are some
of us who disagree with your reasons for objecting to the inclusion of
[]s, it doesn't mean that we're objecting to the inclusion and use of
(,). Indeed, as I'm sure I've already said in this thread, I'm in
favour of (,). Just because you think it has to be either [][] or (,),
it doesn't mean the rest of us do, too.

There is no reason to have two functions that do the same thing. You
should really pick one or the other. If there is a legacy issue it
should be deemed deprecated and only included for backwards compat.
All code using the function in question should be changed.

Again, the second [] need not immediately follow the first.

 

[Simon G Best]

I want to use normal Array[ROW][COL] Syntax.
Why?

To eliminate the humongous learning curve cost of violating a universal
standard.

IMHO, that's a good reason to use common syntax.
I disagree with the C++ FAQ. This FAQ is created by one person, and
its contents are not determined by any formal peer review.
The C++ FAQ is a good guideline, but it should not be taken as
indisputable facts by any measure.


Consider the following methods:
http://code.axter.com/dynamic_2d_array.h
> http://www.codeguru.com/forum/showthread.php?t=297838

Yuk! That's exactly what *not* to do. Your implementation is exposed
through your interface - bad! Or, two quote R2-D2, "your parts are
showing." operator[] simply should not have a return type that is tied
to the implementation, or which needlessly restricts the implementation.

Also, why should your two-dimensional array be presented as an array of
rows, but not as an array of columns?

 

[Daniel T.]

Daniel T. wrote:

The entire post below is merely my opinion and, as such, unassailable.

I don't see a consensus about what *should be* used. I don't say that both
access should be implemented, nor that any of them should not be
implemented. And I don't see that the majority of the people say that
things.

It could just be my optimism. But it seemed to me that most people have
said they would/have implement(ed) both access methods in their matrix
classes.

What I say, and I think others also says in essence, is that the arguments
in the C++ FAQ Lite against the usage of [ ] [ ] are biased and
questionables, and the redaction of the points in question tends to give
the false impression that the syntax of the interface and the details of
the implementation are directly related.

Here I will agree that the FAQ is biased, the author seems to believe
that implementation hiding and complete yet minimal interfaces are a
good idea and doesn't support his reasoning for that.

(I remember when Scott Meyers came out with his algorithm and
justification for complete yet minimal interfaces. He got a lot of heat
for it [including from me at the time] but now, for these types of low
level classes, I think he was right on the mark.)

And that people can have good reasons to use the [ ] [ ] syntax, with legacy
or non-legacy code. This reasons need not to be acceptable to all people
for all his matrix-alike class to be valid. The point is not to encourage
people to use that syntax, is about to not encourage to not use it.

The above doesn't address what the FAQ says, rather what you think it
implies. I think it implies something different:

IMO, the FAQ is directed toward new programmers who think the only way
to correctly create a multi-dimensional array class is by somehow
overloading the op[]. I feel it is important, when some newbie is
struggling with how to load up a vector of vectors (possibly even
deeper. Or worse manually newing several arrays,) to point out to him
that his life would be easer if he created a class with an appropriate
interface, and point out some simpler implementations he can use for
that interface. Then later if he complains that it takes up too much
RAM, I can easily show him an implementation that takes less without him
having to rewrite the entire program.

I think the code in FAQ 13.10 and 11 do a great job of getting a newbie
started on the right track for making multi-dimensional arrays in
general. I think Marshall's comments in FAQ 13.12 are a reaction to
emails Marshall received from people who came to the language from C,
have been programming for a long time, and have lost sight of the fact
that the FAQ is for beginners, not experts. In it he gives advice for
the more advanced programmer on how to implement [][] if they want or
need to, such that it has all the advantages of the (,) approach.

That said, I recently found FAQs 16.16 to 16.19 (when were these put
in?) and may direct new people to them instead.

If someone has a point against the usage of ( , ) is a completely different
topic.

Accepted.

 

[Michael DOUBEZ]

Daniel T. a écrit :

Gianni Mariani a écrit :

Daniel T. wrote:
...
On Jan 3 you said, "The FAQ does state many false claims in support of
the position of using (,) over [][]." How about you state one assertion
that is in the FAQ that you think is false and let's see what happens.
Just one of the many you say exist so we don't get too distracted.
Read this post:
http://groups.google.com.au/group/comp.lang.c++/msg/c3bbd70542232ca6?dmode=s
ource&hl=en

I explained it all paragraph by paragraph. What more do you want ?

A critic of what you said:
- You said: "As you can see, the FAQ bases all the claims on the
false assumption that by using [][], you cannot implement optimizations
using (,)."
- The FAQ says: "The array-of-array solution obviously works, but
it is less flexible than the operator() approach. Specifically, there
are easy performance tuning tricks that can be done with the operator()
approach that are more difficult in the [][] approach, and therefore the
[][] approach is more likely to lead to bad performance, at least in
some cases."

Keep in mind Michael, that quote is about a particular implementation of
[][]. Read the paragraph before and after it.

Too bad you cut the following sentence.
I was just pointing out the difference between the reading of Gianni
Marianni and the content of the FAQ as I read it.

Concerning the particular implementation, I read in the paragraph before:
"[...]Some people build a Matrix class that has an operator[] that
returns a reference to an Array object [...] and that Array object has
an operator[] that returns an element of the Matrix.[...]"

This seems pretty general for me and since there is no operator[][], I
don't see the alternative. Which particular implementation are you
talking about ?

Michael

 

[Simon G Best]

Care to give specifics, or do you prefer to remain as ambiguous as the
FAQ on this matter.

It's just basic stuff. Proper encapsulation, and so on.

 

[Simon G Best]

Nope. It is not a definition. It is a claim. I can easily be proven wrong if
someone shows a reasonable compiler that does not optimize away the
proxies. Feel free to do that.

I'd say that any compiler that conforms to the C++ standard is
reasonable. If the C++ standard does not - implicitly or explicitly -
require the optimizing away of such proxies, then there can be
reasonable compilers that don't optimize them away.

But...

....

To warn against such
techniques because some compilers may do a poor job on optimization is a
case of premature optimization.

Indeed, indeed! We generally shouldn't be designing our interfaces on
the basis of internal optimization issues in the first place.

Furthermore, in those cases where speed really is an issue, we should
probably use std::valarray<>s, slices and generalised slices, and the
like, instead, anyway.

Anyway, I'm not too sure it's really worth arguing with Daniel T about
this stuff, as he seems to keep forgetting stuff that's already been
dealt with.

 

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

It could just be my optimism. But it seemed to me that most people have
said they would/have implement(ed) both access methods in their matrix
classes.

In a matrix-alike class directed to the more general usage possible, I think
I will implement access to elements with [ ] [ ], with ( , ), and with a
member function with name. People that like minimal interfaces but wants to
use this class can just encapsulate it and expose only the interface
wanted, after all.

IMO, the FAQ is directed toward new programmers who think the only way
to correctly create a multi-dimensional array class is by somehow
overloading the op[]. I feel it is important, when some newbie is
struggling with how to load up a vector of vectors (possibly even
deeper.

I can agree with that, but many points of the reasoning are inadequate for
that purpose. Give to newbies the impression that the interface is directly
related with the details of the implementation is no good. And emotional
arguments as seen in the last point of the FAQ about the matter is worse
IMO.

I think the code in FAQ 13.10 and 11 do a great job of getting a newbie
started on the right track for making multi-dimensional arrays in
general. I think Marshall's comments in FAQ 13.12 are a reaction to
emails Marshall received from people who came to the language from C,

Maybe, but in any case arguing about changes on internal data structure in a
point whose title is about the interface is unfortunate. But taking apart
the opinions about his reasoning, the mood of 13.12 in inadequate. Sounds
like "I'm sure I'm right, if you don't understand my reasons is your
fault".

have been programming for a long time, and have lost sight of the fact
that the FAQ is for beginners, not experts. In it he gives advice for
the more advanced programmer on how to implement [][] if they want or
need to, such that it has all the advantages of the (,) approach.
That said, I recently found FAQs 16.16 to 16.19 (when were these put
in?) and may direct new people to them instead.

A good idea. The content of that points looks no polemic and highly valuable
for beginners. The proxy approach, if desired by him, can be learned later.

 

[Simon G Best]

Those expressions, however, make my life much easier. My main issue with the
FAQ entry on matrices is that it creates the misguided impression that
element access (although of course an important primitive) is the main
issue in interface design for a matrix class.

....

Similarly, the main problem I've got with those FAQs is the assumption
that the only reason someone would have for wanting []s in the interface
is to say "[j]" instead of "(i, j)". But, of course, that assumption
is incorrect. While there are some people who would simply rather say
"[j]" than "(i, j)", and while there is old code that has "[j]",
there is, as you rightly say, a lot more to it than that. Put simply,
the application of the first [] may well be in a different place to the
application of the second (such when they're in different functions).

 

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

It is not a mix, from my point of view, the decision tree is the
following: Pre: I have two solutions for matrix script access: 1. [][] and
2. (,)
Q1. Can I implement both ?
R1. Preferabily not, it would only confuse user (i.e. minimal interface
is preferable)

I understand your point of view, but the main point is that the FAQ says
something much more categoric:

"[13.10] How do I create a subscript operator for a Matrix class?
Use operator() rather than operator[]."

You don't have to if you don't want. People that have a reason to do it
will evaluate if the risk is low enough to him. That is all the point,
that saying that it never be used is an inadequate over-generalization.

And the FAQ doesn't say differently: in general, it is good practise to
use (,) and for specific reason you can use [][] at some potential cost.

The FAQ says what I quote in the previous paragraph. Later he says: "Put it
this way: the operator() approach is never worse than, and sometimes better
than, the [][] approach.". This point is reasonable, but is highly
questionable that this is a definitive reason to never user such interface
unless you are strongly forced to, as he says.

The point is to call 'special' cases where people implement risky stuff
when they have a safe alternative (i.e. have reason not to use the
general best practice).

This is another way of saying: my reasons are better than yours.

No, I mean I will not add a useless interface. If accessor f() is
already implemented, there is no good reason that I can think of to

In this thread several reasons of several people had been mentioned. If you
choose to ignore it or not consider it good, is just your subjective point
of view.

Personnaly, I don't see any problem or trial of coercition in the FAQ.

Read again the 13.10 entry I quoted.

 

[Simon G Best]

I recommend using standard syntax [][] over the non standard ambiguous
(,) method.

[][] is no more, nor less, standard than (,). If you think [][] is more
standard than (,), then please refer us to the relevant part of the C++
standard that says [][] is standard.

More importantly, the []s in [][] are not for the same purposes as (,).

The first [] in [][] should be for treating the two-dimensional array as
a one-dimensional array-like thing (an array of rows or columns). The
second [] should be for treating a row or column as a one-dimensional
array-like thing as well (an array of actual elements). (But then the
question is: should the two-dimensional array be presented as an array
of rows or as an array of columns? The answer is probably: both! But
then there's the question: how can that be done? There are a few
answers to that question.)

(,), in contrast, should be for treating the two-dimensional array as a
function of pairs of indices. That's a reasonable way of viewing a
two-dimensional array, so that use of operator() is appropriate.

 

[Daniel T.]

Daniel T. a écrit :

- The FAQ says: "The array-of-array solution obviously works,
but it is less flexible than the operator() approach.
Specifically, there are easy performance tuning tricks that can
be done with the operator() approach that are more difficult in
the [][] approach, and therefore the [][] approach is more
likely to lead to bad performance, at least in some cases."

Keep in mind Michael, that quote is about a particular
implementation of [][]. Read the paragraph before and after it.

Concerning the particular implementation, I read in the paragraph
before: "[...]Some people build a Matrix class that has an
operator[] that returns a reference to an Array object [...] and
that Array object has an operator[] that returns an element of the
Matrix.[...]"

This seems pretty general for me and since there is no operator[][],
I don't see the alternative. Which particular implementation are you
talking about ?

I think the FAQ, in showing the proxy solution, is making a distinction
between that solution and others like the one that Peter presented that
started off this thread and the vector of vectors solution.

 

[Daniel T.]

Daniel T. wrote: ...

Again IMO, and according to the FAQ, calling op(,) is a better
method of accessing a single element of the array (as opposed
to calling op[] and then op[] on the result.) Now this is
something that several seem to be disagreeing with, but
frankly I don't understand why.

No, I really think you've got that wrong. Just because there
are some of us who disagree with your reasons for objecting to
the inclusion of []s, it doesn't mean that we're objecting to
the inclusion and use of (,). Indeed, as I'm sure I've already
said in this thread, I'm in favour of (,). Just because you
think it has to be either [][] or (,), it doesn't mean the rest
of us do, too.

There is no reason to have two functions that do the same thing.
You should really pick one or the other. If there is a legacy
issue it should be deemed deprecated and only included for
backwards compat. All code using the function in question should
be changed.

Again, the second [] need not immediately follow the first.

And there is no reason that can't be done with the (,) interface and an
external binder. However, such comments have nothing to do with the
veracity of the FAQ.

 

[Peter Olcott]

Daniel T. a écrit :

- The FAQ says: "The array-of-array solution obviously works,
but it is less flexible than the operator() approach.
Specifically, there are easy performance tuning tricks that can
be done with the operator() approach that are more difficult in
the [][] approach, and therefore the [][] approach is more
likely to lead to bad performance, at least in some cases."

Keep in mind Michael, that quote is about a particular
implementation of [][]. Read the paragraph before and after it.

Concerning the particular implementation, I read in the paragraph
before: "[...]Some people build a Matrix class that has an
operator[] that returns a reference to an Array object [...] and
that Array object has an operator[] that returns an element of the
Matrix.[...]"

This seems pretty general for me and since there is no operator[][],
I don't see the alternative. Which particular implementation are you
talking about ?

I think the FAQ, in showing the proxy solution, is making a distinction
between that solution and others like the one that Peter presented that
started off this thread and the vector of vectors solution.

I like Gianni Mariani's solution the best for several reasons:
(1) It is very machine efficient. In my case this is utterly crucial.
(2) It is very simple, thus its reliability can be reliably validated.
(3) It uses the same standard convention for multiple dimension array access as
is native to its language, thus minimizing the learning curve and typing error
rate

 

[Simon G Best]

As has been said before, [][] can be used with regular POD array of
array as well as matrix classes and a matrix function template could
easily provide the basis for both regular POD types as well as matrix
classes if the class supported the [][] syntax. That's a big bonus.

Except that it's better to avoid C-style POD arrays in the first place.
Even when we have to deal with them, it's better to wrap them up in
proper interfaces and then go through the interfaces. That means we're
only dealing directly with the POD arrays in one place, which is preferable.

Finally the most critical one is ambiguilty. var[][] is very easy to
identify as a subscript operation while var(,) can easily be confused as
a function call, i.e. there is no learning curve.

I'm not convinced. operator[] is a function, and may well return
something other than what might naively be expected. It could, for
example, return a proxy, rather than an ordinary reference. If someone
naively thought that "var[][]" was ordinary, C-style subscripting,
they'd be mistaken, and would actually be misunderstanding the
interface. They might try to do "var[]", and find it doesn't do what
they expected.

Also, presenting a matrix as a function of pairs of indices to
referenced elements is not unreasonable. And operator() /is/ a
function, after all. What's more, there's nothing wrong or unusual in
having function objects and calling them as such. It would be a mistake
for someone to naively assume that "var(,)" must be an invocation of an
ordinary function.

As is so often said: *C++ is not C!*

 

[Simon G Best]

I recommend using standard syntax [][] over the non standard ambiguous
(,) method.

There is nothing at all non-standard or ambiguous about function calls.

It's non-standard in that it's not the standard method for referencing
an array.

That myth has already been debunked in this thread.

Example of ambiguous usage:

x = foofo(1, 3);

Is foofoo a function, or is foofoo an array. The above syntax does not
make that clear.

But if you don't know what foofoo is, you don't know what foofoo(1, 3)
is or does, either. If you /do/ know what foofoo is, then there's no
ambiguity. And anyway, there's nothing wrong or unusual in having
function objects and using them as such.

The following syntax is less ambiguous:
x = foofoo[1][3];

Except operator[] /is/ a function, and doesn't necessarily return what
someone might naively think. It might, for example, return some kind of
proxy, rather than the kind of reference that might be naively expected.

As is so often said: *C++ is not C!*