Can we override [][] ?

[Jakob Bieling]

Re: Can we override [][] ?

boaz_sade@yahoo .com wrote:
[color=blue]
> 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.[/color]

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]

Re: Can we override [][] ?

Noah Roberts wrote:[color=blue]
> Axter wrote:[color=green]
> > Noah Roberts wrote:[color=darkred]
> > > 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[/color]
> >
> > I recommend NOT following this particular FAQ.
> > It uses contrive logic to support promoting the use of non-standard
> > syntax to reference a matrix.[/color]
>
> "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].[color=green]
> >
> > I recommend using standard syntax [][] over more ambiguous ()() method.[/color]
>
> "ambiguous" ? What is so special about [][] that makes it less
> ambiguous than ()?
>[color=green]
> > I also recommmend using vector<vector<T > > type.[/color]
>
> Can't enforce size.
> Requires dynamic allocation.
> Etc...etc...
>[color=green]
> >
> > See following links for example implementations :
> > http://code.axter.com/dynamic_2d_array.h[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
> > http://www.codeguru.com/forum/showthread.php?t=231046[/color]
>
> Also very incomplete[/color]

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.
[color=blue]
> 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.[/color]

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.

[color=blue]
> 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.[/color]

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.

[color=blue][color=green]
>>The ones you have provided are dangerous, incomplete, and[/color]
> useless in the real world.[/color]

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@yahoo.com]

Re: Can we override [][] ?


Jakob Bieling wrote:[color=blue]
> boaz_sade@yahoo .com wrote:
>[color=green]
> > 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.[/color]
>
> 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)[/color]
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@yahoo.com]

Re: Can we override [][] ?


Jim Langston wrote:[color=blue]
> <boaz_sade@yaho o.com> wrote in message
> news:1149060064 .215475.206760@ i40g2000cwc.goo glegroups.com.. .
>
> Noah Roberts wrote:
> <snipping stuff unrelated to answer[color=green]
> > 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.[/color]
>
> 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?[/color]

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 :)

[Earl Purple]

Re: Can we override [][] ?

FYI my own matrix class allows both syntaxes.

operator[] returns a (template) class, known either as
portable_ref_bu ffer or portable_cref_b uffer. These are standalone
classes that are used in other places as well. Both have a pointer and
length but with portable_ref_bu ffer the pointer is non-const, and
portable_cref_b uffer has a constructor from portable_ref_bu ffer. In
both cases it's a weak pointer, i.e. the class does not own the
pointer. (thus "ref" in the name, it references its memory, And
portable because it's safely portable across libraries).

portable_cref_b uffer and portable_ref_bu ffer both have operator[]
overloaded. In both cases the overload is a const member and returns
the pointer.

Both classes have member functions begin(), end(), empty() and size()
so can be used in algorithms like for_each. begin() is guaranteed to
return a pointer so it's safe to pass to functions that require a
pointer. If empty, begin() is safe as long as you don't attempt to
dereference it.

Both classes have an implicit constructor from a vector - either a
const or non-const reference depending on which class it is. They
cannot be resized though.

[Noah Roberts]

Re: Can we override [][] ?


Axter wrote:
[color=blue]
> 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.[/color]

Actually it is. As you said, it offers nothing over using a C array
and therefor is pointless extra code that serves no purpose.
[color=blue]
> If you need something that requires bounds checking, then you should
> not use it.
> The class is not intended for that purpose.[/color]

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.[color=blue]
>[color=green][color=darkred]
> > > http://www.codeguru.com/forum/showthread.php?t=231046[/color]
> >
> > Also very incomplete[/color]
>
> These are example skeleton classes. They don't have to be complete.[/color]

They don't even qualify as "example skeleton classes" and that is at
least not how the first is being advertized.
[color=blue]
> They just need enough to get the point across as to how to get a [][]
> interface.[/color]

In a piss poor and dangerous manner.[color=blue]
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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.
[color=blue]
> The implementations I posted as examples, are reasonable for their
> purpose.[/color]

I pointed out several reasons they are not...you haven't answered those
reasons.[color=blue]
>
>[color=green][color=darkred]
> >>The ones you have provided are dangerous, incomplete, and[/color]
> > useless in the real world.[/color]
>
> And again, they're no more dangerous then using static size C-Style
> arrays.[/color]

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.
[color=blue]
> It's incorrect to believe that all code requires bounds checking.[/color]

And I never said it was.
[color=blue]
> 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.[/color]

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.
[color=blue]
>
> 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.[/color]

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.[color=blue]
>
> IMHO, this FAQ is wrong, and I posted alternative skeleton examples
> that can be used as a template for user's custom matrix class.[/color]

Well, I've given several reasons why they don't qualify for that. They
need major revisions.
[color=blue]
>
> IMHO, your nonconstructive comments do a disservice to the C++
> community and to this newsgroup.[/color]

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.

[Noah Roberts]

Re: Can we override [][] ?


Jakob Bieling wrote:[color=blue]
> boaz_sade@yahoo .com wrote:
>[color=green]
> > 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.[/color]
>
> What is this 'something' you are referring to?[/color]

That your code shouldn't be depending on what type your objects are so
long as they respond to the interface you expect them to.

And how does it[color=blue]
> relate to using "C" as a prefix for class names?[/color]

C as in "this is a class" indicates that the programmer wants to know
if the types he is working with are classes or not...but his code
shouldn't care and therefore he/she shouldn't care either. Also what
happens when you decide that a class isn't the best implementation but
maybe it should just be a struct instead. You gonna change to strName
all over the damn place?

Hungarian notation is a bastard child that should have been aborted.
Too often I see code written in it where someone said, "Hey, I need
another variation of that true/false value so I'll change to char," but
then they didn't want to have to change the name all over the place so
they left it as bFlag instead of iFlag.

[Axter]

Re: Can we override [][] ?

Noah Roberts wrote:[color=blue]
> Axter wrote:
>
> 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.[/color]

The example skeleton classes will remain as is, since they serve their
purpose, whether you want to believe it or not.

If you think your comments are constructive, then you're either
ignorant, or have no manners. IMHO, it's most likely both.

Good day.... I said Good day!!! ;-)

[Earl Purple]

Re: Can we override [][] ?


Axter wrote:[color=blue][color=green]
>> If you think your comments are constructive, then you're either[/color]
> ignorant, or have no manners. IMHO, it's most likely both.[/color]

This is becoming too much of a flame war. But there was some
constructive criticism in there. Let me see if I can point it out:

template < class T>
class dynamic_2d_arra y
{
public:
dynamic_2d_arra y(size_t row, size_t col):m_row(row) ,m_col(col),
m_data((row!=0& &col!=0)?new T[row*col]:NULL){}
dynamic_2d_arra y(const
dynamic_2d_arra y&src):m_row(sr c.m_row),m_col( src.m_col),
m_data((src.m_r ow!=0&&src.m_co l!=0)?new T[src.m_row*src.m _col]:NULL){
for(size_t r=0;r<m_row;++r )for(size_t c=0;c<m_col;++c ) (*this)[r][c]
= src[r][c];
}
~dynamic_2d_arr ay(){if(m_data) delete []m_data;}
inline T* operator[](size_t i) {return (m_data + (m_col*i));}
inline T const*const operator[](size_t i) const {return (m_data +
(m_col*i));}
protected:
dynamic_2d_arra y& operator=(const dynamic_2d_arra y&);
private:
const size_t m_row;
const size_t m_col;
T* m_data;
};

1. No method to retrieve back the dimensions. Easy enough to modify.
Add in:

size_t rows() const { return m_row; }
size_t cols() const { return m_col }

2. protected section when class cannot be inherited. Minor detail but
operator= is automatically disabled for this class anyway due to it
having const members.

3. no need to check for NULL in destructor

4. To access the data you call matrix[0] which is unclear notation.

5. Your copy constructor is probably slower than you think as you are
calculating the position a lot of times. But as the arrays are
identical in size you can do member-by-member copy. If you're really
advanced you'll have an is_pod<> traits-style function and use memcpy
when is_pod returns true.

I would actually say it is a bit inconsistent to allow
copy-construction but not assignment. Whilst you cannot resize,
assignment might be useful, and could be "optimised" when the two
matrices already the same dimensions by not doing a new allocation. In
fact, if the capacity of the current matrix is enough to hold the new
contents you might be able to optimise.

If you use a nested vector then resizing can be done with vector's
member resize() function.

[Noah Roberts]

Re: Can we override [][] ?


Axter wrote:[color=blue]
> Noah Roberts wrote:[color=green]
> > Axter wrote:
> >
> > 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.[/color]
>
> The example skeleton classes will remain as is, since they serve their
> purpose, whether you want to believe it or not.[/color]

Well, whatever. As examples on how to implement [][] I have to say
they are inadiquate and could easily lead a person down a bad path
because of what they omit. The answer is not as simple as you make it
out to be and considering it so can cause problems for people who might
listen to you. But in the end I guess they will learn the hard way. I
also used to force [][] into interfaces years ago when I was first
starting so I know the trouble they are in for. I learned, so will
they...some won't obviously.

[Jack Saalweachter]

Re: Can we override [][] ?

Noah Roberts wrote:[color=blue]
> "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].[/color]
Cute in an "oh god don't ever do that" sort of way:

struct MagicInt {
// operator overloads, constructors, etc, to make this class behave
// as an integer.
};

std::pair<Magic Int, MagicInt> operator , (const MagicInt &a, const
MagicInt& b) { return std::make_pair( a, b); }

class Array2d {
public:
value& operator[](const std::pair<Magic Int, MagicInt> &a) {
// use a.first and a.second to find the value...
}
};

int main() {
Array2d M(X, Y);

for (MagicInt a = 0; a < X; ++a)
for (MagicInt b = 0; b < Y; ++b)
M[a, b] = i + j;
}


So, 'M[a, b]' is *implementable* , even if so brittlely that you'd never
want to use it. (For instance, you cannot say 'M[1, 2]'.)



Jack Saalweachter

[Noah Roberts]

Re: Can we override [][] ?


Earl Purple wrote:[color=blue]
> Axter wrote:[color=green][color=darkred]
> >> If you think your comments are constructive, then you're either[/color]
> > ignorant, or have no manners. IMHO, it's most likely both.[/color]
>
> This is becoming too much of a flame war.[/color]

Yes, I suppose I am being a bit agressive but I have already pointed
out these and more problems with the code he is passing off as advice.

I also think it interesting that he claims this is a "skeleton example"
yet this is the comment in the top of that file:

// dynamic_2d_arra y class by David Maisonave (609-345-1007)
(www.axter.com)
// Description:
// The dynamic array class listed below is more efficient then other
// similar classes that use temporary objects as return types, or use
// an std::vector as a return type.
//
// 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.
// Example usage:

Doesn't look like it is thought of as a "skeleton template" to me.
Looks like it is an attempt to document a complete class. That and the
documentation even documents a feature that isn't there, namely the
retreval of the raw data storage for use in a function requiring an
array or pointer. The fact that you CAN do this is actually a bug in
the interface that can be exploited to provide functionality that
wasn't built in.

I just hate seing stuff like this passed off as expert advice
especially when he is attempting to get beginners to move contrary to
the FAQ. Sure, the FAQ could be wrong but if your going to move
against it provide something more complete, safe, and coherent. There
can be compelling reasons that [][] needs to be in the interface but
his "expert" code is not a good way to implement it and gives the
misconception that it is simple to do, and it is far from it unless you
want to stab yourself in the ass. He compares his implementation to
the STL yet it provides none of the safety features or abstractions the
STL does. It's just bad code that exhibits bad practices (as well as
being VERY difficult to read) and I think it better to point this out.

There are people I consider experts in this field and I don't always
agree with everything they say but I acknowledge they are several
levels above me. I also write questionable code and know it...but then
I'm not calling myself an expert. Axter claims to be an expert,
exclaiming how he is top rated expert this or that on website X, but
his code says otherwise.

[Noah Roberts]

Re: Can we override [][] ?


Jack Saalweachter wrote:[color=blue]
> Noah Roberts wrote:[color=green]
> > "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].[/color]
> Cute in an "oh god don't ever do that" sort of way:[/color]

Wow....I bow down to your abilities to spread evil. I can only hope to
be that good someday ;)

Assuming it works, and it looks to me like it would. Ouch...

[Marcus Kwok]

Re: Can we override [][] ?

Noah Roberts <roberts.noah@g mail.com> wrote:[color=blue]
> Hungarian notation is a bastard child that should have been aborted.
> Too often I see code written in it where someone said, "Hey, I need
> another variation of that true/false value so I'll change to char," but
> then they didn't want to have to change the name all over the place so
> they left it as bFlag instead of iFlag.[/color]

I actually read an article just today on how Hungarian notation itself
has become horribly bastardized, and it is this bad version of it that
everybody knows and many people dislike. Essentially, in the original
paper, the author (Charles Simonyi) used the word "type" instead of
"kind", and people took it too literally, thus destroying the original
usefulness.

http://joelonsoftware.com/articles/Wrong.html

(near the bottom of the article)

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Noah Roberts]

Re: Can we override [][] ?


Marcus Kwok wrote:[color=blue]
> Noah Roberts <roberts.noah@g mail.com> wrote:[color=green]
> > Hungarian notation is a bastard child that should have been aborted.
> > Too often I see code written in it where someone said, "Hey, I need
> > another variation of that true/false value so I'll change to char," but
> > then they didn't want to have to change the name all over the place so
> > they left it as bFlag instead of iFlag.[/color]
>
> I actually read an article just today on how Hungarian notation itself
> has become horribly bastardized, and it is this bad version of it that
> everybody knows and many people dislike. Essentially, in the original
> paper, the author (Charles Simonyi) used the word "type" instead of
> "kind", and people took it too literally, thus destroying the original
> usefulness.
>
> http://joelonsoftware.com/articles/Wrong.html
> (near the bottom of the article)[/color]

So basically it is saying things should be named based on what their
interface is no? For instance something that is a "Copier" might be
better named as a "CopierComm and" if it was in fact a "Command".
Instances of this class should reflect what they will do.

That makes sense to me but I debate whether HN is verbose enough for
that. I also believe classes and variable names should reflect what
they are meant to do but I like to be a little more verbose about it
most of the time.