Can we override [][] ?

[Jim Langston]

I wanted to do an operator override for [][] but couldnt' figure out the
syntax. I tried this (code that doesn't compile commented out with //:

class CMyBitmap
{
public:
CMyBitmap( int Rows, int Columns ): Rows_( Rows ), Columns_( Columns )
{
Data_ = new SPixel[ Rows * Columns ];
}
~CMyBitmap()
{
delete[] Data_;
}

// error C2804: binary 'operator [' has too many parameters
// SPixel& operator[]( const int Row, const int Column )
// {
// return Data_[ Columns_ * Row + Column ];
// }

// error C2092: '[]' array element type cannot be function
// SPixel& operator[][]( const int Row, const int Column )

SPixel& Pixel( const int Row, const int Column )
{
return Data_[ Columns_ * Row + Column ];
}

private:
SPixel* Data_;
int Rows_;
int Columns_;

// No copy or assignment yet so disable by making private.
CMyBitmap ( CMyBitmap const& ) {};
CMyBitmap& operator=( CMyBitmap const& ) {};

};

Can we override 2d array access?

[Tomás]

Jim Langston posted:

union SPixel
{
struct {
unsigned char B, G, R, A;
};
unsigned long Value;
};

Platform-specific code, I realise. (What you're trying to do can be quite
easily achieved portably though.)
However, even if you're guaranteed that:

(1) "unsigned long" is four bytes.
(2) Your target architecture is Bigendian.

The compiler is still within its rights to put padding between any of B G
R A.

The slightly more portable solution (but still non-portable nonetheless)
would be:

struct SPixel {

unsigned long Value;

unsigned char &B, &G, &R, &A;

SPixel() :
B( reinterpret_cas t<unsigned char&>(Value) ),
G( *(reinterpret_c ast<unsigned char*>(&Value) + 1) ),
R( *(reinterpret_c ast<unsigned char*>(&Value) + 2) ),
A( *(reinterpret_c ast<unsigned char*>(&Value) + 3) )
{}
};
I'd criticise your code in a few places (in fact I'd rewrite it
altogether in a portable way), but if it gets the job done for you, then
so be it.

Expect MASSIVE problems though if you change architecture or platform.

-Tomás

[Noah Roberts]

Axter wrote:

Noah Roberts wrote:

Jim Langston wrote:

I wanted to do an operator override for [][] but couldnt' figure out the
syntax.
http://www.parashift.com/c++-faq-lit...html#faq-13.10

I recommend NOT following this particular FAQ.
It uses contrive logic to support promoting the use of non-standard
syntax to reference a matrix.

"Non-standard"? Non-standard to who? Certainly not the domain which
uses subscript notation and/or M(a,b)...or the unimplmentable M[a,b].
I recommend using standard syntax [][] over more ambiguous ()() method.
"ambiguous" ? What is so special about [][] that makes it less
ambiguous than ()?
I also recommmend using vector<vector<T > > type.
Can't enforce size.
Requires dynamic allocation.
Etc...etc...

See following links for example implementations :
http://code.axter.com/dynamic_2d_array.h
Above example is horrid still. Again it may track its own size but it
neither provides bounds checking nor does it provide a client interface
to retrieve bounds so there is frankly no reason for it to track its
size at all (only m_col is used and neither are accessable). The fact
that it contains redudant check for null of a pointer wouldn't be so
bad if it wasn't being passed off as an example and didn't have so many
other problems.

As for ambiguity...the comments state that, "It's also more compatible
with a C style 2D array, in that the array is in one continuous memory
block. This makes it possible to pass this array object to a C Function
that has a C-Style 2D array for a parameter." Unfortunately it doesn't
provide an interface to retrieve the m_data field and pass it to such a
function. The only way to do it is to yet again use [] in a way that
creates icky dependencies and sets a piss poor president for future
code:

cFunThatAccepts CStyleMatrix(ma trix[0]).

This class has numerous usability problems and creates too many damn
dependencies. It looks like the code a rank beginner would come up
with, exhibiting several newbie problems, yet its being passed off as
an expert example to use contrary to a FAQ written by obvious upper
level programmers. Seems to me like you might want your ducks more in
row for such an attempt.

delete [] matrix[0]; anyone?

How about this one:

dynamic_2d_arra y<int> m1(5,5);
dynamic_2d_arra y<int> *m2 = new dynamic_2d_arra y<int>(m1); // perfectly
reasonable thing to do...

I don't understand the reasoning behind placing operator= under the
protected safetynet either...seems more appropriate to make private to
me. Not virtual...not useful...only dangerous.
http://www.codeguru.com/forum/showthread.php?t=231046
Also very incomplete but still offers several features yours does
not...unfortuna tely they work inconsistently. For example...getti ng
the size of a row is no problem but how to retrieve the row count??
Availability of row size is only due to return of [] . This dependency
is not necissary if the matrix class was just implemented more
completely. This version is better than the first but worse than
simply using vector<vector<T > > because it hides the encapsulating
vector for no reason and provides no access to necissary information
that vector would hold....yet exposes the internal vector to the
public...ick.

Also a rather inefficient implementation due to the reasons you
describe in the first...I agree that a single, contiguous array is much
more efficient.
http://www.codeguru.com/forum/showth...hreadid=297838

Just a repost of the first link.

I suggest that if you are going to argue with this newsgroup's faqs you
should at least provide reasonable implementations of what you deem the
correct way. The ones you have provided are dangerous, incomplete, and
useless in the real world. Again, rank beginners often come up with
better code than your first implementation (couldn't do a whole lot
worse) and could very easily do better than the second. I have to
point out these facts because with you passing it off as an example of
'correct' coding contrary to the faq I think anyone that might not
otherwise be should be made aware of the numerous flaws in your
code...of which I only touched half.

[Noah Roberts]

Tomás wrote:

int main()
{
ChessBoard board;

board[3][5] = ChessBoard::Squ are::bishop;
}
As you can see, a simple member function (or even function-style
operator) would probably be better.

Yes. The concept of forcing [][] on an object because it is
implemented with an array is inherently flawed. Try implementing [][]
with a bitboard for example and then compare that implementation to
functional notation.

class Board
{
private:

uint64 white_pieces;
uint64 black_pieces;
uint64 white_knights;
....
? operator[](uint row);

// easier and more appropriate:
piece pieceAt(uint row, uint col);
piece operator()(uint row, uint col);
};

There is question of how piece would be found and what it is but the
client doesn't need to worry on that. Doesn't require a bunch of extra
proxy wrappers to forcably create an unnatural syntax and doesn't clue
the client in nor cause them to depend upon the internal representation
of this Board class.

Now, in actually building a chess engine you're probably going to break
encapsulation anyway and create massive dependencies just to speed
things up a hair (if you've never done it let me tell you that a LOT of
time is spent trying to get just a little more oomph out of your
classes) but at any rate this is a perfect example of what happens when
you think, "Hey this is an array, lets make it look like one..." Well,
what happens when you decide it shouldn't be implemented with an array
anymore??

[boaz_sade]

Noah Roberts wrote:

Tomás wrote:

int main()
{
ChessBoard board;

board[3][5] = ChessBoard::Squ are::bishop;
}
As you can see, a simple member function (or even function-style
operator) would probably be better.

Yes. The concept of forcing [][] on an object because it is
implemented with an array is inherently flawed. Try implementing [][]
with a bitboard for example and then compare that implementation to
functional notation.

class Board
{
private:

uint64 white_pieces;
uint64 black_pieces;
uint64 white_knights;
....
? operator[](uint row);

// easier and more appropriate:
piece pieceAt(uint row, uint col);
piece operator()(uint row, uint col);
};

There is question of how piece would be found and what it is but the
client doesn't need to worry on that. Doesn't require a bunch of extra
proxy wrappers to forcably create an unnatural syntax and doesn't clue
the client in nor cause them to depend upon the internal representation
of this Board class.

Now, in actually building a chess engine you're probably going to break
encapsulation anyway and create massive dependencies just to speed
things up a hair (if you've never done it let me tell you that a LOT of
time is spent trying to get just a little more oomph out of your
classes) but at any rate this is a perfect example of what happens when
you think, "Hey this is an array, lets make it look like one..." Well,
what happens when you decide it shouldn't be implemented with an array
anymore??

You wrote:
"but at any rate this is a perfect example of what happens when
you think, "Hey this is an array, lets make it look like one..." Well,
what happens when you decide it shouldn't be implemented with an array
anymore?? "
I must say I cannot see your point. The rational of using operator
overloading is not whether the internals of the class are with array or
something else. It is intending to make it look like array. Anyone
using C++ is accustom to using [] for accessing continues memory. This
is why you have it in std::vector and std::string but you don't at
std::list. The point is to use a code that it is easier to read. If we
were using FORTRAN then we may have preferred to using operator () and
not operator [] for subscripting. Anyways since other gave poor
implementations to the operator [] doesn't mean there are no other
better ones. You can take a look in Stroustrup's "The C++ programming
language" book for one good implementation using STL internals. There
is anther one in boost, and yet more in various matrix various
libraries (such as blitz++) and there are many more (tough I bet you
will find them flowed as well). This is programming and not
engineering!. There is no perfect solution, just a rational that you
may or may not accept. If one solution not suits you then you can find
anther that may.
Anyways - The main problem is the above code starts from the fact that
he using "C" prefixing in his class name - which is good indication
that he misses something important in programming. The second is that
this is "one time" solution - if you need 2D array and you need bit map
then first you have those two unrelated concepts be separately
implemented. From there you can continue. This may lead to the fact
that in this case you don't need "operator [] []" which I think too in
not relevant in this case.

[Jim Langston]

<bo*******@yaho o.com> wrote in message
news:11******** **************@ i40g2000cwc.goo glegroups.com.. .

Noah Roberts wrote:
<snipping stuff unrelated to answer

Anyways - The main problem is the above code starts from the fact that
he using "C" prefixing in his class name - which is good indication
that he misses something important in programming. The second is that
this is "one time" solution - if you need 2D array and you need bit map
then first you have those two unrelated concepts be separately
implemented. From there you can continue. This may lead to the fact
that in this case you don't need "operator [] []" which I think too in
not relevant in this case.

Not this old argument again. This has been discussed many times in this
newsgroup, and different people prefer to distinguish classes from instances
in different ways. Some use capital letters for class names and small
letters for instant variables. Some use some form of prefix, some use some
formm of suffix. Some don't distinguish in anyway.

I prefer to use a prefix of 'C' Now, what is wrong with that? Where does
that break any rule of good programming?

And in this case the bitmap and the 2D array are not unrelated, because in
this case it's the only reason to allocate the memory. If I was doing the
full project (which I'm not) I'm sure I would totally refactor it and this
class would look totally different and be given a different name, and may
not actually exist.

This class was created because someone needed 2D array access to memory that
could be looked at as R,B,G,A values or all four values in one int. Which
is all this class does. How is the 2D array access and looking at R,B,G,A
values different in this particular case?

[Jakob Bieling]

bo*******@yahoo .com wrote:

Anyways - The main problem is the above code starts from the fact that
he using "C" prefixing in his class name - which is good indication
that he misses something important in programming.

What is this 'something' you are referring to? And how does it
relate to using "C" as a prefix for class names?

regards
--
jb

(reply address in rot13, unscramble first)

[Axter]

Noah Roberts wrote:

Axter wrote:

Noah Roberts wrote:

Jim Langston wrote:
> I wanted to do an operator override for [][] but couldnt' figure out the
> syntax.

http://www.parashift.com/c++-faq-lit...html#faq-13.10
I recommend NOT following this particular FAQ.
It uses contrive logic to support promoting the use of non-standard
syntax to reference a matrix.

"Non-standard"? Non-standard to who? Certainly not the domain which
uses subscript notation and/or M(a,b)...or the unimplmentable M[a,b].

I recommend using standard syntax [][] over more ambiguous ()() method.

"ambiguous" ? What is so special about [][] that makes it less
ambiguous than ()?

I also recommmend using vector<vector<T > > type.

Can't enforce size.
Requires dynamic allocation.
Etc...etc...

See following links for example implementations :
http://code.axter.com/dynamic_2d_array.h

Above example is horrid still. Again it may track its own size but it
neither provides bounds checking nor does it provide a client interface
to retrieve bounds so there is frankly no reason for it to track its
size at all (only m_col is used and neither are accessable). The fact
that it contains redudant check for null of a pointer wouldn't be so
bad if it wasn't being passed off as an example and didn't have so many
other problems.

The purpose of the dynamic_2d_arra y, is to give a dynamic version of a
static size C-style array.
It's no more or no less safer then using a static C-Style array, and
therefore, no more horrid then using a static size C-Style array.
If you need something that requires bounds checking, then you should
not use it.
The class is not intended for that purpose.

http://www.codeguru.com/forum/showthread.php?t=231046

Also very incomplete

These are example skeleton classes. They don't have to be complete.
They just need enough to get the point across as to how to get a [][]
interface.
Also a rather inefficient implementation due to the reasons you
describe in the first...I agree that a single, contiguous array is much
more efficient.
I heard this from most programmers, who don't have the experience in
actually testing this theory out.
I've conducted test, shows your above comment to be false.
Try testing this in RELEASE version, and you'll find very little
difference in performance.
In fact, some implementations have better performance with a
vector<vector< > >, then with a contiguous array.

I suggest that if you are going to argue with this newsgroup's faqs you
should at least provide reasonable implementations of what you deem the
correct way.

I suggest, that you first test your theories before making performance
claims on this newsgroup.
The implementations I posted as examples, are reasonable for their
purpose.

The ones you have provided are dangerous, incomplete, and

useless in the real world.

And again, they're no more dangerous then using static size C-Style
arrays.
It's incorrect to believe that all code requires bounds checking.
That's why the C++ standard doesn't require that STL have bounds
checking.
If' it's good for the standard, then it's good for a skeleton example
implementation.

Following an FAQ blindly, is a mistake.
This C++ FAQ is created by one person, and he is no more or no less
prone to mistakes then any other experience programmer.

IMHO, this FAQ is wrong, and I posted alternative skeleton examples
that can be used as a template for user's custom matrix class.

IMHO, your nonconstructive comments do a disservice to the C++
community and to this newsgroup.

[boaz_sade]

Jakob Bieling wrote:

bo*******@yahoo .com wrote:

Anyways - The main problem is the above code starts from the fact that
he using "C" prefixing in his class name - which is good indication
that he misses something important in programming.

What is this 'something' you are referring to? And how does it
relate to using "C" as a prefix for class names?

regards
--
jb

(reply address in rot13, unscramble first)

The reason you can find in MFC class names prefixing with C in their
names is that when Microsoft implemented MFC namespaces were not widely
supported in many compilers. In order to have their class names unique
they used C prefix to all MFC class names. Many inexperience
programmers seeing the practices from Microsoft and following them
blindly. I believe that anyone who is doing those king if thing is
missing a key understanding in using whatever tool he/she is trying to
use.
Basically it's should bather anyone seeing others placing their own
code under namespace std just because the standard library is doing it
too
Hope that now you can understand why I think this is truly a band
practice

[boaz_sade]

Jim Langston wrote:

<bo*******@yaho o.com> wrote in message
news:11******** **************@ i40g2000cwc.goo glegroups.com.. .

Noah Roberts wrote:
<snipping stuff unrelated to answer

Anyways - The main problem is the above code starts from the fact that
he using "C" prefixing in his class name - which is good indication
that he misses something important in programming. The second is that
this is "one time" solution - if you need 2D array and you need bit map
then first you have those two unrelated concepts be separately
implemented. From there you can continue. This may lead to the fact
that in this case you don't need "operator [] []" which I think too in
not relevant in this case.

Not this old argument again. This has been discussed many times in this
newsgroup, and different people prefer to distinguish classes from instances
in different ways. Some use capital letters for class names and small
letters for instant variables. Some use some form of prefix, some use some
formm of suffix. Some don't distinguish in anyway.

I prefer to use a prefix of 'C' Now, what is wrong with that? Where does
that break any rule of good programming?

And in this case the bitmap and the 2D array are not unrelated, because in
this case it's the only reason to allocate the memory. If I was doing the
full project (which I'm not) I'm sure I would totally refactor it and this
class would look totally different and be given a different name, and may
not actually exist.

This class was created because someone needed 2D array access to memory that
could be looked at as R,B,G,A values or all four values in one int. Which
is all this class does. How is the 2D array access and looking at R,B,G,A
values different in this particular case?

As for the C prefix see my replay to someone else bellow. As for the
Bitmap - why should we care about how do store it. You can the 2D
matrix is your own care so use it as "as - a". But more generally,
sometime in the future you will need 2D matrix for other use and then
you will simply write anther implementation of 2D matrix for this other
use. 2D matrix is one concept that can be used for many application in
which bitmap is just one of them. A good programmer will write 2D
matrix class (or better yet find good code writing by someone like the
boost people or other experience programmers) and concentrated he/her
efforts on the "real" code of the project - in this case the bit map
algorithm itself.
Good luck :)

[Noah Roberts]

Axter wrote:

The purpose of the dynamic_2d_arra y, is to give a dynamic version of a
static size C-style array.
It's no more or no less safer then using a static C-Style array, and
therefore, no more horrid then using a static size C-Style array.
Actually it is. As you said, it offers nothing over using a C array
and therefor is pointless extra code that serves no purpose.
If you need something that requires bounds checking, then you should
not use it.
The class is not intended for that purpose.
It should at least provide access to the bounds it is tracking so
clients don't have to wrap it in a class that does.

http://www.codeguru.com/forum/showthread.php?t=231046
Also very incomplete

These are example skeleton classes. They don't have to be complete.

They don't even qualify as "example skeleton classes" and that is at
least not how the first is being advertized.
They just need enough to get the point across as to how to get a [][]
interface.
In a piss poor and dangerous manner.

Also a rather inefficient implementation due to the reasons you
describe in the first...I agree that a single, contiguous array is much
more efficient.
I heard this from most programmers, who don't have the experience in
actually testing this theory out.
I've conducted test, shows your above comment to be false.

Interesting, then why do you yourself make it?

Besides, if your tests are anything like your example code then they
are completely meaningless. If they test your example code they are
equally so.
The implementations I posted as examples, are reasonable for their
purpose.
I pointed out several reasons they are not...you haven't answered those
reasons.

The ones you have provided are dangerous, incomplete, and useless in the real world.

And again, they're no more dangerous then using static size C-Style
arrays.

Correct. They are also no less so. In fact the first one provides
absolutely no benefits over a simple array whatsoever. The second
provides no benefits over vector<vector<> > and in fact removes access
to important information that would be available by just using
vector<vector<> >. Your classes are pointless at best.
It's incorrect to believe that all code requires bounds checking.
And I never said it was.
That's why the C++ standard doesn't require that STL have bounds
checking.
If' it's good for the standard, then it's good for a skeleton example
implementation.
Every single container class in the standard library has a size()
member function and in fact at least one of the containers does provide
bounds checking. Another initializes new contents on access to a non
existant index... All STL container classes also provide several
protective abstractions surrounding the internal implementation
including iterators and reference proxies. Yes, if you know what a
particular implementation looks like you can get past those as they are
only typedefs but still, it is an abstraction that can be used in a
safe and consistant manner. Your classes don't do any of these
things...your classes are sluts.

Yes, these classes are a far cry short of the STL.

Following an FAQ blindly, is a mistake.
This C++ FAQ is created by one person, and he is no more or no less
prone to mistakes then any other experience programmer.
Yes, following the FAQ blindly is a mistake. I've seen several
examples of implementing [][] that are not the newbie hackery that
yours is. I prefer to listen until I find a compelling reason not
to...your reasoning and your examples are far from compelling and in
fact are compelling arguments for the FAQ as your forcing of [][] on
this concept has led you to create monsters.
IMHO, this FAQ is wrong, and I posted alternative skeleton examples
that can be used as a template for user's custom matrix class.
Well, I've given several reasons why they don't qualify for that. They
need major revisions.

IMHO, your nonconstructive comments do a disservice to the C++
community and to this newsgroup.

You may see them as noncunstructive if you want. I am not surprised as
you continue to pass these off as "expert guidance" and so wouldn't
want to hear that they actually exemplify several horrendous beginner
mistakes but whatever.