«

Axter wrote:

> The purpose of the dynamic_2d_array, 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 **** 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.

Jakob Bieling wrote:
> 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?

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
> relate to using "C" as a prefix for class names?

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.

Noah Roberts wrote:
> 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.

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!!!

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

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_array
{
public:
dynamic_2d_array(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_array(const
dynamic_2d_array&src):m_row(src.m_row),m_col(src.m _col),
m_data((src.m_row!=0&&src.m_col!=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_array(){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_array& operator=(const dynamic_2d_array&);
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.

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

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.

Noah Roberts wrote:
> "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].
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:air<MagicInt, MagicInt> operator , (const MagicInt &a, const
MagicInt& b) { return std::make_pair(a, b); }

class Array2d {
public:
value& operator[](const std:air<MagicInt, 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

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

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_array 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.

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

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...

Noah Roberts <> wrote:
> 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.

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

Marcus Kwok wrote:
> Noah Roberts <> wrote:
> > 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.
>
> 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)

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 "CopierCommand" 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.