Two-Dimensional Dynamic Arrays

[Peter Olcott]

I need to know how to get the solution mentioned below to work. The
solution is from gbayles Jan 29 2001, 12:50 pm, link is provided below:

http://groups.google.com/group/comp....c43260a5310?hl

Another way is to create a one dimensional array and handle the
indexing yourself (index = row * row_size + col). This is readily
implemented in template classes that can create dynamically allocated
multi-dimensional arrays of any element type and number of
dimensions.

What would be the syntax for created a template that allowed a
one dimensional dynamic array, to be addressed using the conventional
syntax for accessing a two dimensional array? I am thinking that this
must be some sort of operator[] overloading.

Thanks,
Peter Olcott

[Gianni Mariani]

ro**********@gmail.com wrote:

Why not just return &&array[x]

Notice how the () syntax keeps encapsulation without the need of an
adapter even with 2d and with 3d still doesn't need one.

plonk

[roberts.noah]

Axter wrote:

I forgot to mention that your wrapper class also fails to have a GetCol
and GetRow function.
You are of course right and that is an obvious problem except for one
thing. The presented class is an adapter to provide () syntax when
using a C array. Since someone that needs that adapter is already
using a C array outside of a class and so is tracking the dimensions
already the GetCol and GetRow functions would be redundant. However,
since the addition of these functions is relatively straight forward
and could come of use, possibly, their ommision is probably a mistake.

As you also state, I could have also improved it to also adapt vectors.
Also check out another CodeGuru STL FAQ:
http://www.codeguru.com/forum/showth...hreadid=297838

The above link has two classes. One which I'm the author of, and the
second class which allows you to use both [][] and operator() method.
I don't think it's a good idea to have both methods in a class, but
some developers may find this method more acceptable.

Decent:
http://www.codeguru.com/forum/showth...hreadid=231046

Still has a dependency that could be removed. It could be more
abstract. No matter how you slice it the interface still spells out a
particular alignment. This is forgivable but with op() that problem
doesn't exist so that is still +1 for op().

The reason this version is better is that because it returns a vector
reference instead of pointer to a memory chunk; therefor the class is
protected from clients trying to overwrite into a second row on
accident. The vector interface is sufficient to offer protection in
this area and it still retains a great deal of efficiency. Basically
the vector is acting a lot like the previously supplied "proxy".

On the other hand, this class doesn't seem that necessary. Why not
just use the vector<vector<> > in the open? The only really nice thing
this class offers is the sizing of the internal vectors. Makes me
wonder if the constructor shouldn't just call resize.

The other link you have above... The first class is no good; it is the
same trash you already posted in fact - why are you wasting everyone's
time like that? Do you think that by looking at it somewhere else it
will change the problems inherent in its design??

Second implementation also has problems but is several degrees better
than yours. I would remove the op[]'s. The iterator idea was great
but could have been expanded to include columns. getRow is dangerous
and has the same problems as op[] - I think it would be better to stay
with the iterator idea and toss getRow or just make it return an
iterator.

[roberts.noah]

Gianni Mariani wrote:

ro**********@gmail.com wrote:

Why not just return &&array[x]

Notice how the () syntax keeps encapsulation without the need of an
adapter even with 2d and with 3d still doesn't need one.

plonk

Coward.

[roberts.noah]

ro**********@gmail.com wrote:

Decent:
http://www.codeguru.com/forum/showth...hreadid=231046

Come to think of it, I like it less now that I think on it....not for a
real 2d matrix anyway - or anything where rows should be the same
length. Reason is simple:

T t();

mtx[x].push_back(t);

This is ok, since the class doesn't stop you from doing it (and can't)
but it's rather ugly. The purpose of this class seems pretty straight
forward in that the above call shouldn't be allowable even though it
is. This is a pretty tricky problem though and I'm not surprised it
slipped past the developer (maybe it didn't and they decided to live
with it). The answer is of course that some sort of policy is created
that is self enforced by developers...someone usually breaks that kind
of policy though. Any client that used the iterator interface or based
its operation on .size() could break down with the above, buggered mtx.

It's a point against it anyway. You can do the same with
vector<vector<> > but at least that isn't pretending to be rectangular.
The single chunk of memory solution also seems to have the possibility
at least of being more efficient....less redirections.

Of course this is also caused by an encapsulation issue. I tricked
myself into thinking it would be ok in this case. Just goes to show I
guess.

You could fix this by returning a class that *contains* the vector (or
non-public inheritance) that did not provide the functions that would
pose the problem. This works because it fixes the encapsulation issue.
If you thought ahead enough this returned class could be based on
something abstract that could be implemented in any number of
manners...meaning the vectors wouldn't even have to be there at all.

In the end it is similar to the previous example and I still think the
() interface still ends up providing the same benefits with less work.

[jrp]

I can see both sides of the argument so far, but would like to explore
a bit further real world usage and performance of such classes,
including with"legacy" code.

The first thing that most of the above examples would need is const
versions of many of the operations; the second is that it needs to be
possible to use an aligned malloc to allocate storage to get the
benfits of vectorization. Finally, it needs to be possible to allocate
the memory so that there is no aliasing (or do so via a restrict
decoration).

To be more specifif, suppose that I want to build a system of 3d
numeric objects (cubes) that can be sliced into 2 and 1d objects
(planes, rows), and those 2d objects can also be sliced into 1d rows.
And I want to be able to present those rows to legacy C routines that
expect C arrays and lengths. I also want to be able to do things like

acube = 0;
acube[nplane] = 0;

aplane[nrow] =0;

acube[nplane] = aplane;

and present an acube[nplane] to a routine as a const Plane& parameter.

(using () if necessary).

As I understand it, the original intention was for valarray + slice to
do this job but that seems to be harder to achieve efficiently and
usable.

There are those that say use Blitz++, or boost::multi_array, or
stlorg::fixed_array. These are heavy packages, yet none of them seems
to provide a drop-in replacement for the ugly but functional
vector<vector<vector>>> and [][][].
It would be helpful to discuss this on the basis of some concrete
candidate classes such as those earlier in the thread so that we can
test performance / applicability. For example, are address
dereferences slower than int multiplications?

[Axter]

ro**********@gmail.com wrote:

ro**********@gmail.com wrote:

Decent:
http://www.codeguru.com/forum/showth...hreadid=231046

Come to think of it, I like it less now that I think on it....not for a
real 2d matrix anyway - or anything where rows should be the same
length. Reason is simple:

T t();

mtx[x].push_back(t);

This is ok, since the class doesn't stop you from doing it (and can't)
but it's rather ugly. The purpose of this class seems pretty straight
forward in that the above call shouldn't be allowable even though it
is. This is a pretty tricky problem though and I'm not surprised it
slipped past the developer (maybe it didn't and they decided to live
with it). The answer is of course that some sort of policy is created
that is self enforced by developers...someone usually breaks that kind
of policy though. Any client that used the iterator interface or based
its operation on .size() could break down with the above, buggered mtx.

It's a point against it anyway. You can do the same with
vector<vector<> > but at least that isn't pretending to be rectangular.
The single chunk of memory solution also seems to have the possibility
at least of being more efficient....less redirections.

Of course this is also caused by an encapsulation issue. I tricked
myself into thinking it would be ok in this case. Just goes to show I
guess.

You could fix this by returning a class that *contains* the vector (or
non-public inheritance) that did not provide the functions that would
pose the problem. This works because it fixes the encapsulation issue.
If you thought ahead enough this returned class could be based on
something abstract that could be implemented in any number of
manners...meaning the vectors wouldn't even have to be there at all.

In the end it is similar to the previous example and I still think the
() interface still ends up providing the same benefits with less work.

I know you among others, don't seem to see a syntax problem with using
operator(), but here's a small example of how using operator() instead
of [][] can make your code ambiguous.
CMatrix arr(12, 34);
..... lost of other code ....
..... losts more code ....
int x = arr(1, 3);// Is arr a function, or a class????

If arr is far removed from it's declaration, a normal assumption would
be to think arr is a function, and the above line of code is calling a
global arr function.

int x = arr[1][3]; // This is much less ambiguous, and easy to identify
arr as an array

Using operator() for arrays makes the code more confusing, and harder
to read and maintain, where as using [][] is straight forward, and very
easy to pick what's going on in above line of code.
Why use ambiguous syntax when you don't have to?????

[Kai-Uwe Bux]

Axter wrote:

[snip] I know you among others, don't seem to see a syntax problem with using
operator(), but here's a small example of how using operator() instead
of [][] can make your code ambiguous.
CMatrix arr(12, 34);
.... lost of other code ....
.... losts more code ....
int x = arr(1, 3);// Is arr a function, or a class????

If arr is far removed from it's declaration, a normal assumption would
be to think arr is a function, and the above line of code is calling a
global arr function.

int x = arr[1][3]; // This is much less ambiguous, and easy to identify
arr as an array

Using operator() for arrays makes the code more confusing, and harder
to read and maintain, where as using [][] is straight forward, and very
easy to pick what's going on in above line of code.
Why use ambiguous syntax when you don't have to?????

To me, it seems that the problem in this code does not arise from
overloading operator(). It arises from choosing a poor variable name. C++
has the feature of allowing for function objects. Therefore, any expression
like

identifier( arg_1, arg_2, arg_3 );

could be a function call, creation of a temporary, invoking operator(), or
maybe even more. The way to cope with this "ambiguity" is not to ban
overloading operator() but to choose identifiers wisely so that an object
of type CMatrix can be recognized as such.
Best

Kai-Uwe Bux

[Axter]

Kai-Uwe Bux wrote:

Axter wrote:

[snip]

I know you among others, don't seem to see a syntax problem with using
operator(), but here's a small example of how using operator() instead
of [][] can make your code ambiguous.
CMatrix arr(12, 34);
.... lost of other code ....
.... losts more code ....
int x = arr(1, 3);// Is arr a function, or a class????

If arr is far removed from it's declaration, a normal assumption would
be to think arr is a function, and the above line of code is calling a
global arr function.

int x = arr[1][3]; // This is much less ambiguous, and easy to identify
arr as an array

Using operator() for arrays makes the code more confusing, and harder
to read and maintain, where as using [][] is straight forward, and very
easy to pick what's going on in above line of code.
Why use ambiguous syntax when you don't have to?????

To me, it seems that the problem in this code does not arise from
overloading operator(). It arises from choosing a poor variable name. C++
has the feature of allowing for function objects. Therefore, any expression
like

I agree, but you find too many developers that will use short
initialized names, that may be perfectly clear to them, but complete
ambiguous to the next developer that has to maintain his/her code.
I'm not advocating a ban on using operator(). I just don't think using
it in place of [][] is appropriate, and leads to ambiguous code.

[roberts.noah]

jrp wrote:

To be more specifif, suppose that I want to build a system of 3d
numeric objects (cubes) that can be sliced into 2 and 1d objects
(planes, rows), and those 2d objects can also be sliced into 1d rows.
And I want to be able to present those rows to legacy C routines that
expect C arrays and lengths. I also want to be able to do things like

acube = 0;
acube[nplane] = 0;
I take it that the above is filling with 0's? I see the need for such
an operation but I am not sure I like the syntax. You could also be
meaning (especially in the top instance) assign to this cube with a
cube with no dimensions.
aplane[nrow] =0;

acube[nplane] = aplane;
I can also see the need for this operation but I think the syntax is
flawed here as well. Do you mean X, Y, or Z axis plane? Functional
syntax would be better here I think. Could be a single function
getPlane(x, axis) or three seperate for each axis.
and present an acube[nplane] to a routine as a const Plane& parameter.
Or even a non const. Seems you would also want to be able to pass
planes, rows, or individual items to manipulators.
It would be helpful to discuss this on the basis of some concrete
candidate classes such as those earlier in the thread so that we can
test performance / applicability. For example, are address
dereferences slower than int multiplications?

I would add a requirement. You must be able to create a new class that
stores its data in a different manner, possibly col mjr form but could
be anything, that will work as a parameter to any function or algorithm
that expects the designed class.

I'll play but it will take a while as time is an issue.

[jrp]

Thanks. I won't quibble about the syntax (although there is a logic to
it). What interests me is ((empirical) relative performance, including
vectorizability) and completeness: so missing const versions of
operators are an issue, and may help to tip the balance for those
interested in clutter / complexity.

I'll play but it will take a while as time is an issue.

Thanks. Likewise. Happy to contribute, if necessary.

[jrp]

Oh, and some other example (based on projections on a base array)

http://www.math.ualberta.ca/~bowman/Array

http://www.bluesailsoftware.com/software/aptl/

http://www.netwood.net/~edwin/svmtl/

http://www.research.att.com/~bs/matrix.c

as well as heavyweights such as POOMA