operator[][](const int i, const int j)

[dude_1967]

Hello gurus,

I am developing a two-dimensional matrix template class and I need help with a syntax problem.

It is common to write the operator[](const int n) for one-dimensional data arrays.

Is it possible to write the operator[][](const int i, const int j) for two-dimensional data arrays? If so, then what is the proper syntax. Maybe someone can work it into my sample code.

Here is a slimmed down version of the code in question in case anyone really wants to get into this one and help me out.

Thanks for any help.

Chris.



#include <iostream>

template<typename T> class c_matrix
{
private:

T** data;
const int nrow;
const int ncol;
bool valid;

public:

c_matrix(const int nr, const int nc) : nrow(nr), ncol(nc)
{
valid = true;

data = new(std::nothrow) T*[nrow];

if(data == NULL)
{
valid = false;
return;
}

register int i;
for(i = 0; i < nrow; i++)
{
data[i] = new(std::nothrow) T[ncol];
if(data[i] == NULL)
{
valid = false;
return;
}
}
}

~c_matrix()
{
if(valid)
{
int i;
for(i = 0; i < nrow; i++)
{
delete [] data[i];
}
delete [] data;
}
}

public:

// I would like to write operator[][](const int i, const int j) if possible

const void set(const int i, const int j, const T& value)
{
if(valid)
{
data[i][j] = value;
}
}

const T& get(const int i, const int j) const
{
if(valid)
{
return data[i][j];
}
else
{
static const T zero = 0;
return zero;
}
}

const int row(void) const { return ncol; }
const int col(void) const { return nrow; }

};

template<typename T>
inline ::std::ostream& operator<<(::std::ostream& os, const c_matrix<T>& m)
{
register int i;
for(i = 0; i < m.row(); i++)
{
register int j;
for(j = 0; j < m.col(); j++)
{
os << m.get(i, j) << '\t';
}
if(i != m.row() - 1 && j != m.col() - 1)
{
os << std::endl;
}
}
return os;
}

int main(int argc, char* argv[])
{

c_matrix<double> m(3, 3);

// I would like to write m[0][0] = +1

m.set(0, 0, +1);
m.set(0, 1, +2);
m.set(0, 2, +3);

m.set(1, 0, -1);
m.set(1, 1, +2);
m.set(1, 2, 0);

m.set(2, 0, +7);
m.set(2, 1, +6);
m.set(2, 2, -2);

std::cout << m << std::endl;

return 1;
}

[Graham]

Nope.

Your best bet is to have c_matrix::operator[] return a vector class (this could be a nested class inside c_matrix, or it could be independent). The vector class would then implement its own operator[] to get at the scalar.

[Graham]

Sorry, bare outilne of code structure:

template<typename T>
class c_matrix
{
public:
template<typename U>
class vect
{
public:
U operator[](int i);
};

vect<T> operator[](int i);
};

You might need to muck around with reference to const, or whatever, but's the basic idea...

[dude_1967]

Right on!

Thanks Graham. Based on your tip a working solution has been implemented.

Chris.

:)

[Zeeshan]

Take a look at this artical of CUJ

http://www.cuj.com/articles/2000/0012/0012c/0012c.htm

It might solve all of your problemes.

Hope it helps.

[AnthonyMai]

What kind of trouble you guys are going though in merely fetching an element from a 2D array, just so that you can use the square bracket? Is it worth it?

Returning a vector is a NO NO, unless you want your computer to take 8 months to carry out a calculation that could be done in 15 seconds. Also keep in mind any returned objects are temporary clone of the original object so operations on such temporary object will be lost. An excellent example is Paul's "index sorting using std::sort" sample code in which he used a functor object which contains a vector which is a copy of the original vector to be sorted. As a result of the functor being copies over and over within std::sort, a 1 second operation ends up taking several weeks.

I don't see a reason why one has to insist on using syntax like this:

myVal = my2DArray[x][y];

How about this instead:

myVal = my2DArray(x, y);


And your class can be implemented much easier like this, without the crap of cascading two operators:

template <typename T, int X, int Y>
class DUMMY
{
public:
T m_data[X][Y];

T operator() (int x, int y)
{
return m_data[x][y];
};
};
//...In main()
DUMMY<int, 16, 16> dummy;
//...
myVal = dummy(1,2);

[PaulWendt]

I actually liked the article linked to by Zeeshan; it pretty much has
what the original poster wanted ... for what I'd consider to be a
reasonable efficiency hit. Obviously if performance is key, you
might want to either optimize or use another solution, but I think
that stressing performance ALL of the time is a waste of time. I
think that maintenance is just as much a factor [if not more of a
factor] than performance in most cases.

In my opinion, the () overloading is a great solution performance-
wise ... but it just doesn't look the same. It really looks just like a
function call. If you're going to do that, I'd rather just see a
function get(int,int). Operator overloading is just syntactic sugar
anyway; if you're going to use an operator for a use it's not
intended for, then you're just going to confuse people.

You're right that returning any object with a complicated copy-
constructor is a bad thing. I'm not quite sure how long it'd take
to copy a vector of int's, but if there's a better solution, then stick
with it. I agree that performance is important too, but not at the
sake of confusing things. I think operator() is meant for certain
purposes and giving it another use is confusing. It'd be similar
to me using operator+ as a pointer deference on a smart pointer
of mine because [for some reason] implementing operator* would
cost me a little CPU time [even though getting into this scenario
would be difficult].

--Paul

[Paul McKenzie]

An excellent example is Paul's "index sorting using std::sort" sample code in which he used a functor object which contains a vector which is a copy of the original vector to be sorted. As a result of the functor being copies over and over within std::sort, a 1 second operation ends up taking several weeks.So fix it if it takes so long, Mr. Debugging Guru. And please, don't use your buggy, non-compliant, compiler-crashing QSort function.

Also, don't bring up my name in any of your posts to make your wild claims. You get on enough nerves here -- why exascerbate the problem even further?

Regards,

Paul McKenzie

[AnthonyMai]

Obviously if performance is key, you
might want to either optimize or use another solution, but I think
that stressing performance ALL of the time is a waste of time. I
think that maintenance is just as much a factor [if not more of a
factor] than performance in most cases.


Performance is NOT important all the time. If you are programming a calculator or writting a home financing application. Performance is not an issue at all.

But my viewpoint is, computers are around for so many decades, all those none-performance critical applications that people can possibly conceive, chances are some one has already thought about it and there are already plenty of competing products out there.

The only product that can still fetch money from the market are those that are performance critical ones. Those that could only become a reality very recently due to higher performance hardware and due to extreme software optimization. There are few competition for such product since they simply did not exist one or two years ago.

Or there may be competition but your product wins an edge due to its superior performance.

And there are also products that although doesn't require top nutch hardware, it is also highly beneficial to improve code performance so the task can be achieved on cheaper, low end hardware. The performance of the code may be good enough on a Pentium PC, but you may want to implement the same thing in a $5 toy which contains a processor that costs only $1, and performance becomes critical.

So, in summary, there are very few none-performance critical products that are still out there, that are still market-worthy.
More and more emerging novel products are performance critical.

[PaulWendt]

I both agree and disagree with you. It's nice to see that we can
actually agree about something :) You've always made the
statement that the microprocessor is nearing its performance
peak ... the point at which it will be able to perform no faster. I
have always disagreed with you on this, but it's hard to quantify
until we're actually there. Intel and AMD [and others like IBM]
have huge R&D departments whose sole purpose is to find out
new ways to develop gates. I think the microprocessor AS WE
KNOW IT might be coming to and end soon, but I think that there
will be an incarnation of some form that will exceed the relative
performance of processors we have today. WILL these
companies ultimately succeed? Only time can tell. Neither my nor
your speculation can be worth too much

As far as what products are commercially viable ... I don't know
enough about the real marketplace to answer this question. I do
know that performance can be a consideration. I refuse to believe
that ALL industries are completely saturated with software
products. I think there's still plenty of need for new products. Now
maybe you mean BIG products ... like word processors or what-
have-you. In that case. you're probably right. I'd be hard-pressed
to come out with a word processor that beat's Word in sales. This
is all really six-of-one, half-a-dozen-of-another anyway.

The whole point of my post was that operator() confused the
issue and unless they guy REALLY needed top-notch performance,
I'd recommend against it. Of course, noone can really answer that
question but him. Stylistically, however, I'd prefer to see
operator[] for consistency's sake.

--Paul

[AnthonyMai]

Paul:

My discussion of performance issue is in general. The specific operator() I proposed was NOT meant to be a performance example, although it is definitely more efficient than using two cascaded operator[].

I don't see any thing wrong with using operator () for elements in a N-Dimentional array. It is common mathematics notation like point(x,y,z). OK, so people could confuse it with function calls. But so WHAT? It is indeed function calls. The only confusing possible is people may thought the variable name is a function name, but it is actually a variable name. But just think for a second, such confusion is impossible since people ARE indeed manipulating that variable so they got to know it is their variable.

An analog would be std::sort(), the third parameter you pass in could be a function name, or it could also be a variable name, a variable of the object type commonly known as functor. So when you see this you would wonder whether _P(_V, *_F) is a function call or it is an object calling its operator(). But it really doesn't matter either way.


{_Ty _V = *_M;
if (!_P(_V, *_F))
_Unguarded_insert(_M, _V, _P);
else
{ copy_backward(_F, _M, _M + 1);
*_F = _V; }
}


Back to Moore's Law there are THREE things to keep in mind. One there is physics and physics imposes limit on how far you can go. NASA's Mar's exploration program far inferior than Pentium CPU or something like that, because space radiation will render any thing much more sophisticated than an 8086 totally useless.

The other thing is don't always assume people always want to push on the high end of hardware. If Intel is willing to spend billions of dollars to get their CPU run 10% to 20% faster, software vendors should have plenty of reason to spend millions to get their software run 10 times faster. Why spend money only on the hardware side while there are much more to gain on the software side with much less investment?

The other thing is some people instead want to push on the LOW end of hardware. They want to get something done on hardware that is less sophisticated, hence is cheaper, on hardware that runs at lower clock frequencies and has less gate count, hence consumes less battery power, so it can be made smaller and lasts longer.

I want to be able to listen to the voice as well as see the video, and do a lot of other fancy things on my cell phone. And I want my cell phone to be so small that it fits in my pocket without feeling a thing. And I want it to be manufactured at no more than $10 cost. And I want it to consume so little battery power that I do not need to recharge it every other day. Is that too much to request as a consumer? No. To achieve that goal, you really have to push on the end of software optimization.


I refuse to believe that ALL industries are completely saturated with software products. I think there's still plenty of need for new products.


It is indeed completely saturated with products, especially traditional bloatware, as a matter of fact. The lay offs of the IT industry says it all. They don't need that many programmers. People who have been manipulating strings and vectors for the last two decades are no longer needed. There are simply not many things still left to be done with string manipulation. Too many string classes have been written and re-written.

Any thing that can be conceived and can be done, has been done.

Meanwhile, people who know how to write extremely fast code are still in high demand. There are still a lot of TV set top boxes to be developed, but not enough people who knows how to make it fast enough to be practical on a cheap set top box to do the job.

[jfaust]

We've all heard your arguments and views. They are all opinions that you attempt to pass off as fact.

I've never worked on software that will ever need to be run on cell phones or handhelds or on embedded systems. There is a lot of such software. The software I work on has not been done before. There is a need for it. There will always be a need for it. There will always be a need for improvements on it. Performance is a concern only where performance is an issue. There are many such software companies. There will continue to be.

"The lay offs of the IT industry" have nothing to do with this trend you keep predicting. A similar thing happened in Japan with hardware. They stem from current economic issues, not future trends.

Your arguments are old, boresome, off-topic and wrong.

Jeff

[PaulWendt]

Originally posted by AnthonyMai
I don't see any thing wrong with using operator () for elements in a N-Dimentional array. It is common mathematics notation like point(x,y,z). OK, so people could confuse it with function calls. But so WHAT? It is indeed function calls.

An analog would be std::sort(), the third parameter you pass in could be a function name, or it could also be a variable name, a variable of the object type commonly known as functor. So when you see this you would wonder whether _P(_V, *_F) is a function call or it is an object calling its operator(). But it really doesn't matter either way.

I understand your concern. If the item were meant to act like a
function, I'd let it use operator(). If the item were meant to act
like an array, I'd let it use operator[]. That's what those operators
currently mean ... and I don't want to change the interface. I'm
not saying your idea is wrong; that's irrelevant to the discussion.
I just say that if you're going to use a performance-enhancing
technique, I personally would rather see getAt(int, int) or
at(int,int) than operator() ... because of the reasons I mentioned
earlier. This object isn't conceptually a functor so I wouldn't want
to confuse the issue.


Back to Moore's Law there are THREE things to keep in mind. One there is physics and physics imposes limit on how far you can go. NASA's Mar's exploration program far inferior than Pentium CPU or something like that, because space radiation will render any thing much more sophisticated than an 8086 totally useless.

I think that we might be nearing the limits of the way we currently
perceive processors. I think that they'll either reach a limit and
that'll be it ... or they'll invent some other way that noone else
ever thought of. I think that the latter will happen ... but it's really
moot. You and I each have our own opinion and I doubt we'll
change the other's mind :)


The other thing is don't always assume people always want to push on the high end of hardware. If Intel is willing to spend billions of dollars to get their CPU run 10% to 20% faster, software vendors should have plenty of reason to spend millions to get their software run 10 times faster. Why spend money only on the hardware side while there are much more to gain on the software side with much less investment?

The other thing is some people instead want to push on the LOW end of hardware. They want to get something done on hardware that is less sophisticated, hence is cheaper, on hardware that runs at lower clock frequencies and has less gate count, hence consumes less battery power, so it can be made smaller and lasts longer.

I want to be able to listen to the voice as well as see the video, and do a lot of other fancy things on my cell phone. And I want my cell phone to be so small that it fits in my pocket without feeling a thing. And I want it to be manufactured at no more than $10 cost. And I want it to consume so little battery power that I do not need to recharge it every other day. Is that too much to request as a consumer? No. To achieve that goal, you really have to push on the end of software optimization.

It seems like you're saying that software performance is
extremely important here. I don't think anyone's saying software
should be bloated. Each application has to be evaluated
individually; if there is no need for super performance, then your
arguments are irrelevant. Like another poster said, if my
application doesn't have to be ported to a cell phone ... then I can
afford to take some liberties with respect to processor speed.
In fact, weren't you the one who said that porting to other plat-
forms isn't something you should worry about unless you actually
reach that obstacle? Why start worrying about performance
until you really need it? As long as you're getting the job done
and making your customers happy [including its efficiency] then I
say you're doing a good job.


It is indeed completely saturated with products, especially traditional bloatware, as a matter of fact. The lay offs of the IT industry says it all. They don't need that many programmers. People who have been manipulating strings and vectors for the last two decades are no longer needed. There are simply not many things still left to be done with string manipulation. Too many string classes have been written and re-written.

Any thing that can be conceived and can be done, has been done.

Meanwhile, people who know how to write extremely fast code are still in high demand. There are still a lot of TV set top boxes to be developed, but not enough people who knows how to make it fast enough to be practical on a cheap set top box to do the job.
<laugh> Now this is total rubbish, man. There is no statistic that
states "X% of C++ programmers have lost their jobs whereas
X/4% of asm programmers have lost their jobs". Like the other
poster said, this is all your own personal bias. You have a problem
with C++ because it can produce code less efficient than code you
write yourself. Combined with your ego, that gives you this power
trip leading you to believe that you're superior to all of these
other guys and their feeble C++ programming skills. You're the
programmer who beat Microsoft's qsort() aren't you? You can't be
beaten! Please, Mai. The worldwide economy has more to do
with IT layoffs than anything. I don't think the world is suddenly
in a panic saying "the x86 processor is reading its performance
cap; we must fire all of those incompetent C++ programmers!".
You only wish that'd be the case; then you could laugh from your
self-inhabited ivory tower.

--Paul

[AnthonyMai]

Each application has to be evaluated
individually; if there is no need for super performance, then your
arguments are irrelevant. Like another poster said, if my
application doesn't have to be ported to a cell phone ... then I can
afford to take some liberties with respect to processor speed.


I don't disagree with that. Each piece of code need to be judged individually. And optimization is important only when it matters. The point is cell phone is not the only thing needing performance. The point I want to make is nowadays, in general, there are much more applications that hunger for better performance, than those that does not.

As for the world economy and IT layoffs. IT laid off much more than other industries do. So it is has more to do with the IT itself than the world economy. The fact still remains that the industry has a SURPLUS of programmers. More exactly, surplus of programmers that has skills and experience that's good skill and good experience, but yet unfit for what the industry needs.

The economy is all a supply and demand thing. You are laid off because the company is not making money, the company is not making money because the stuff you created is simply not what people want to have, or it can't compete in the market. Ultimately, it is a world of Darwinism, of survival of the fittest. And the fittest being those who can push efficiency of stuff, be it hardware, software, whatever, to the extreme. The whole history of how the industry civilization progressed is a history of relentless pursuit of power and efficiency. Isn't it true?

[jfaust]

And the fittest being those who can push efficiency of stuff, be it hardware, software, whatever, to the extreme.


Absolutely not true . The right mixture seems to be adequate technology and great sales/marketing. Once you have a technology and a market, a decision needs to be made on the best way to generate revinue with available resources. This may be to make it faster. It may be to add functionality. It may be to advertise. It may be to sell the technology to somebody else. It depends on the application, the user community, competition, market outlook, and many other variables.


The whole history of how the industry civilization progressed is a history of relentless pursuit of power and efficiency.


True, but efficiency to keep production costs down. Optimizing software does not keep production costs down. The two are completely unrelated.


IT laid off much more than other industries do...


Although true, it's a bad argument. It's the IT economy that was the most hurt for various reasons unrelated to technology. Nothing here points to an upcoming paradigm shift.

Jeff

[PaulWendt]

Originally posted by AnthonyMai
The point I want to make is nowadays, in general, there are much more applications that hunger for better performance, than those that does not.

Ultimately, it is a world of Darwinism, of survival of the fittest. And the fittest being those who can push efficiency of stuff, be it hardware, software, whatever, to the extreme. The whole history of how the industry civilization progressed is a history of relentless pursuit of power and efficiency. Isn't it true?


How can you mention bloatware without mentioning Microsoft?
I love Microsoft; I think they changed the face of personal
computing. I abhor all of the idiosyncracies of unix programming
... but no matter how much I love them [and ignore their immoral
business practices], their products are just plain slow.

I certainly wouldn't characterize Microsoft [arguably the leading
software vendor in the world] as pursuing either power or
efficiency. Microsoft has repeatedly shown that it can take a LESS
efficient or LESS technically-sound solution and make it work
through brute-force marketing.

--Paul

[AnthonyMai]

How can you mention bloatware without mentioning Microsoft?
I love Microsoft; I think they changed the face of personal
computing. I abhor all of the idiosyncracies of unix programming
... but no matter how much I love them [and ignore their immoral
business practices], their products are just plain slow.


Believe me I am definitely not a big fan of Micro$oft. But honestly they are neither more bloatware or less bloatware than others. They are just more prominent so we notice.

There was unfortunately an era when bloatwares prevail just like there was an era on earth when bigger and bulkier prevailed and dinasaurs ruled the world. As you know then the ice age came, dinasaurs distincted and leaner animals that are more efficient in predating and in surviving on less food prevailed.


True, but efficiency to keep production costs down. Optimizing software does not keep production costs down. The two are completely unrelated.


Production cost is irrelevant to optimization. Rewards for the time and effort programmers put in creating a software product is generally a very small portion of the "product cost". The extra time and effort one needs to invest in making a software more efficient takes even less portion in the total "production cost", because chances are only 5% of the code are real performance bottlenecks and improve that 5% improves the overall performance.

Microsoft's Windows 2000 contains 39 million lines of code. It was the creation of a team of less than 200 people. Microsoft was said to have invested 5 billion dollars on Win2K, that's $125 per code lines, or $25M per programmer. Now tell me how much do Microsoft programmers actually get paid?

In general, the programmer cost is almost a negligible part of total production cost. The cost of optimization is even less.

[stober]

I've read all your discussions with a lot of interest. I've worked over 10 years optimizing time-critical programs to improve performance, and certainly feel that performance considerations are preferable to bogged-down slow programs all the time, whether the program is a simple calculator or a large real-time program. How many times have you pressed a button in a program and could go to lunch while the program was "thinking" of what to do? I've seen those types of programs and hate them! A few years ago I rewrite one program that took over 12 hours to do its job. That time was reduced to 10 minutes or less.

Client/server database programs are netorious for this. I'm working on an application now that when you press the Submit button the program takes several minutes to process the information. Very little of this time is due to network traffic, but most of it due to careless or inefficient programming. One programmer told me "So what if it takes several minutes!" From a tehnical programmer's view it doesn't really matter at all. But from the user's view -- uggggg! In the trash can with that product!

C++ is a nice programming language and I like it a lot, and programmers can get into the misguided impression that efficiency comes with fewer programming lines. The discussion about the 2d arrays is an example. Nice and easy to read, but runs too slow. Which is more important -- source code that is pretty to look and easy to read but runs like a dog, or source code that may be harder to understand but runs like a champ? Personally, I favor the latter any time.

[jfaust]

From Me:
True, but efficiency to keep production costs down. Optimizing software does not keep production costs down. The two are completely unrelated.


From You:
Production cost is irrelevant to optimization.


If you go back and find the context that I stated that in, you'll realize that that was my point exactly. You were using a flawed argument about efficiency in industry, and I was merely pointing out your flaw. Thanks for agreeing.


Originally posted by stober
source code that is pretty to look and easy to read but runs like a dog, or source code that may be harder to understand but runs like a champ?


This is not a cut-and-dry issue. There is often a direct trade-off between performance and maintainability. Maintainance is the largest cost of software development. The bottom line is the bottom line of the budget. Performance concerns should be secondary to maintanance issues. I am not saying ignore performance. I am saying don't optimize a good design until you have a well-defined bottle-neck and a reason to improve it.

I come from a performance-minded company. We spend a decent amount of time profiling and making improvements. Maintanability is still king. One of our packages has been around for 10 years, the other for 35 (that's right--began with punched cards).

Jeff