The fear of the misterious

This last response (sorry, the last one I'll post -- if you want to see more, go to the newsgroups I've mentioned). This is from someone else called StarDust:

Quote:

---

I'd mention a few things: first, I think it's good to write code that works (as
compared to may work). Second, type safety: with qsort you can errorneously supply
any function taking 2 void* and the compiler won't stop you - results are, as they
say, "undefined". That is not the case with the stl sort, here the compiler will pick
the error. A general heuristic: whenever you see conversions to/from void* you know
you better avoid it.

Third, efficiency: stl sort *generates code* - specifically for your data type,
whereas qsort will rely on a run-time equivalent based on user-supplied type
conversions, which means more indirections (in addition to the possibility of
compiler-uncatcheable type errors).

Copying memory as a method of copying objects (non-PODs) is, I'd say, beyond the pale
w/o even worrying of what can possibly go wrong. There's nothing we know about
internal composition of objects, so that's enough to deem this method in general
verboten.

The guy should learn C++, that's my view of it, since what's at issue here is not
that something *may* work *sometimes*, but that this very thing *may not* work, and
therefore such coding habits should be eliminated. The coder's intent should be to
write code that's 100% guaranteed to work. There'll be enough bugs even with that
assumption, but at least you will have a frame of reference and thus narrow the field
of search for the source of your problems.

---

That's it for the back-and-forth folks. If Anthony wants to respond to Ruslan or StarDust, he knows how to do so.

Regards,

Paul McKenzie

Quote:

---

There's nothing we know about internal composition of objects, so that's enough to deem this method in general verboten.

---

Hmm? You write your own class and you know nothing about its internal composition?

Quote:

---

Copying memory as a method of copying objects (non-PODs) is, I'd say, beyond the pale w/o even worrying of what can possibly go wrong

---

Haven't I made it clear that I am in no way promoting memory copying as a general method of copying objects. I made it clear that you can use memory copying in the context of moving object in memory or swapping, without creating new ones or deleting existing ones, as in the case of sorting Such usage is safe under the restrictions I listed (i.e., the object's property does not depend on its own location). When the restriction is broken, then the objects are not copyable at all.

Quote:

---

The coder's intent should be to
write code that's 100% guaranteed to work.

---

There is no such thing that an application 100% guarantees to work properly. And from my experience, the only thing that is virtually bug-free, are the code that was written in assembly. The reason is simple: You know ever thing that's going on and there is no place for the bug to hide should you make a mistake.

It is a general rule that low level stuff written in low level programming language tends to be more error free and robust. You pick up a telephone and you can always make a phone call. You turn on a DVD player and it always play the video. You hit the break of your car and it always respond. The piece of assebly code that does the voice compression/decompression in your telephone, the piece of codec that processes the digital video data always works in your DVD player. And the software in the micro-chip that controls your anti-lock break works just frawlessly.

On the other hand the higher level you go up, the more likely there are bugs. You don't know how the compiler will interpret your STL code, and you have no control. The higher level you go, the more unknown and uncertain there will be, and the less control you have, and the more bugs you will produce.

StarDust isn't a member of this forum or CodeGuru (AFAIK).

I'll post your response to the comp.lang.c++ newsgroup, since you are not willing to do so. If there is a response, I will not post it here. If you are sure of yourself, you should go there and respond to these fellows.

Again for anyone who is interested, comp.lang.c++, the title of the thread is "memcpy() on objects is safe??".

Regards,

Paul McKenzie

I can't believe you are still arguing. It was amusing at first, but now it's just getting painful. I almost feel sorry for you. As much as anyone can ever be proven wrong, you've been proven wrong. Yet, you persist.

And the nonsense about less bugs in low-level languages is just that--nonsense. But this has very little to do with the OP.

Jeff

I am proven wrong what? I have explained my reasoning, provided sample code. I don't see any of them getting reputed.

Can any one cite even just one example where the object can be copied properly, yet applying qsort on the object array will fail?

Talking about writting correct code, it is MORE likely that you will have a bug in using std::sort() than in the case where you use qsort(). The later will fail if the object is impossible to copy, in which case std::sort() will not work either. And this is a rarely occuring situation.

While as in using std::sort(), if you fail to provide a proper copy constructor or assignment operator where a none-default one is needed, you are doomed.

It is a very likely scenary. Why would you need (bother) to write a copy constructor or assignment operator, if in your own code that you write you are NOT doing any object copying or assigning at all?

Some one tried to prove me wrong by sealing my mouth on this board. That doesn't seem to work. You can not get me to the comp.lang.c++ newsgroup any more than you can get me out of this board. When I am tired here I will leave codeguru. When I am interested I will go visit comp.lang.c++. No one can tell me where to go and where not to go. Meanwhile I am still taking pride of the quality of code that I write.

Your original post was wrong on several accounts--in more ways than I knew. Ruslan Abdikeev pointed these out, described how you were wrong, and then quoted from the standard to back up his claim.

It all boils down to the fact that, according to the standard, you are relying on undefined behavior. I see two choices: 1 -- you think the standard is wrong, or 2 -- it's perfectly OK to rely on undefined behavior. If there's another, please enlighten me.

Jeff

Quote:

---

It all boils down to the fact that, according to the standard, you are relying on undefined behavior. I see two choices: 1 -- you think the standard is wrong, or 2 -- it's perfectly OK to rely on undefined behavior. If there's another, please enlighten me.

---

I agree with first sentence, I disagree with second sentence.
I am using something undefined behavior as far as C++ standard is concerned. Undefined means that the C++ did NOT say any thing about it. It neither said it is right nor said it is wrong. Blank, nothing, null, no comment, nothing was said, zarda.
So whatever I do, it is on separate path from the C++ standard. It does not cross and there is no conflict. OK?

So your first choice is wrong. I do not think the C++ standard is wrong. Nor do I think a standard is right. There is no right or wrong in a standard. For example the standard US paper size is 8.5 inch x 11 inch. Is 8.5x11 right? Or is it wrong? If I use 8 inch x12 inch paper, am I right or wrong?

Standard is not the whole world. It is just by chance and by a lot of consideration that we come to the standard of 8.5x11 paper size. If C++ development has take a slightly different path or the original author has a slightly different philosophy, the C++ standard may be different from what we see today.

Again there is no right or wrong in a standard. The only thing that can be said is whether a C++ standard is good or bad. Or whether the standard is self consistent or not, or whether a piece of code complies with a standard or not.

You can't say a piece of none-compliant code is right or wrong, any more than you can say the standard is right or wrong. Maybe you can say it is good or bad. But good or bad is opinion oriented. Really the only thing that can say whether a piece of code is right or wrong, is whether it can compile and run to produce the desired result.

No. 2. "2 -- it's perfectly OK to rely on undefined behavior"
Undefined in C++ STL standard does not mean it is undefined and comes out totally from the wild. How v-table is implemented is undefined in C++, but it is defined some where else. And it is totally valid to treat the v-table as part of the class members and do memcpy() on them.

Once again my code works, and Philips et al have helped me to verify that it works at least on a number of different platforms. That says enough whether my code is right or wrong.

Quote:

---

Once again my code works, and Philips et al have helped me to verify that it works at least on a number of different platforms. That says enough whether my code is right or wrong.

---

Totally irrelevant. If it says in the standard that the behavior is undefined, then it is undefined. Whether you want to say it or not, you are recommending using undefined behavior as per the ANSI/ISO C++ specification.

As far as you stating that "there is no right or wrong in a standard" -- no comment.

Regards,

Paul McKenzie

Quote:

---

Hmm? You write your own class and you know nothing about its internal composition?

---

Yes you dont know, because it is not define in standard. You should not write the portable code which based on memory structur of class. If it works on one compiler (or plateform) then it doesnt mean it ll run on other plateform (or compiler).

e.g. take a look at this program which i took from my artical "ATL Under the Hood Part 1" Program 15.

Code:

---

#include <iostream>
using namespace std;

class Base1 {
  virtual void f() { cout << "Base1::f" << endl; }
  virtual void g() { cout << "Base1::g" << endl; }
};

class Base2 {
  virtual void f() { cout << "Base2::f" << endl; }
  virtual void g() { cout << "Base2::g" << endl; }
};

class Base3 {
  virtual void f() { cout << "Base3::f" << endl; }
  virtual void g() { cout << "Base3::g" << endl; }
};

class Drive : public Base1, public Base2, public Base3 {
  virtual void fd() { cout << "Drive::fd" << endl; }
  virtual void gd() { cout << "Drive::gd" << endl; }
};

typedef void(*Fun)(void);

int main() {
  Drive objDrive;

  Fun pFun = NULL;

  // calling 1st virtual function of Base1
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+0)+0);
  pFun();
 
  // calling 2nd virtual function of Base1
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+0)+1);
  pFun();

  // calling 1st virtual function of Base2
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+1)+0);
  pFun();

  // calling 2nd virtual function of Base2
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+1)+1);
  pFun();

  // calling 1st virtual function of Base3
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+2)+0);
  pFun();

  // calling 2nd virtual function of Base3
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+2)+1);
  pFun();

  // calling 1st virtual function of Drive
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+0)+2);
  pFun();

  // calling 2nd virtual function of Drive
  pFun = (Fun)*((int*)*(int*)((int*)&objDrive+0)+3);
  pFun();

  return 0;
}

---

This code works fine on VC 6 but crash on Rat Hat Linux 7.0 with gcc 2.96.

Quote:

---

Originally posted by AnthonyMai
Why would you need (bother) to write a copy constructor or assignment operator, if in your own code that you write you are NOT doing any object copying or assigning at all?

---

Because I always consider the copy constructor and copy assignment functions when designing a class:

1) Is copying appropriate? If not, disable copy ctor and copy assign.
2 ) If copying is appropriate, are the compiler-generated functions sufficient? If not, write my own.
3) Is default construction appropriate? Write/disable default ctor as necessary.
4) Is the compiler-generated dtor sufficient? If not, write one.
5) Is the compiler-generated address-of operator sufficient? Almost certainly, but if not, take appropriate action.

Zeeshan:

If what you quoted is indeed from the article you put on CODEGURU, you need to withdraw it right now. Because it is embarrassing to hang it there to show you do not know what you think you know.

What's the difference between a global function and a none-static class member function?

Can you call a none-static class member function the same way you call global function?

Can you call a none-static class member function WITHOUT a class object?

Why?

Hint: there is a hidden parameter "this" when you call a none-static class member function. You know what it is? How it is passed? What will happen if you don't have it?

You are lucky to have it work on VC6 because in your virtual function you are not touching any class data member.

Now back to portability. There CAN be different ways of v-table implementation. There will be a problem when you assume the v-table is located at the beginning of the memory chunk where class data members are allocated. It could well be any where within the memory chunk.

But I made a reasonable, and sensible assumption that no matter how v-table is implemented, it would have to be put into the same chunk of memory where all other class data members sit, not counting the few bytes gap intentionally un-used to make class data members properly byte aligned.

There is just no reasonable way to put data pertaining to a class's state into two different chunks of memory. And I have not seen any implementation does it in such un-thinkable way.

So, unless you can cite one platform on which my assumption is wrong, it is still correct even not spelled out in the C++ standard.
AT least the C++ standard does not say I am wrong. It simple does not say any thing in this regard.

Quote:

---

Why would you need (bother) to write a copy constructor or assignment operator, if in your own code that you write you are NOT doing any object copying or assigning at all?

---

Graham said:

Quote:

---

Because I always consider the copy constructor and copy assignment functions when designing a class:

1) Is copying appropriate? If not, disable copy ctor and copy assign.
2 ) If copying is appropriate, are the compiler-generated functions sufficient? If not, write my own.
3) Is default construction appropriate? Write/disable default ctor as necessary.
4) Is the compiler-generated dtor sufficient? If not, write one.
5) Is the compiler-generated address-of operator sufficient? Almost certainly, but if not, take appropriate action.

---

Graham:

The point is not whether you should write your own copy constructor and copy assignment function. Given any scenary, you ask any one, they will tell you the answer correctly.

The problem is you may FORGET! There are a lot of things that will cause you to forget to write the copy constructor or assignment constructor. And nothing in the compiler will remind you that you missed something. Maybe you initially don't need one, and later you modified something and you need to add one on, but you forget. It's a quite possible scenary.

The problem is, if you see a line of your own code where you assign one object to another, you might remind yourself to check
to make sure you coded the assignment operator. But if you don't do any copying and assigning yourself, what would remind you to make sure that you have provided every thing to baby-sit the ATL underneath, which doesn't even cry when you missed something?

I don't know much about v-tables, but I took the structs
that was given in response to Paul's post, tried to sort
it using qsort() and std::sort().

On VC++ ... no problems
on Portland Group compiler (pgCC) ... a problem. Not only did
qsort() not sort the data, but it mangled the data in the
structure. std::sort() had no problems.

Maybe I am doing something wrong ? Here is the code and
the output ...


<05 [9:30am] /raid > cat test.cpp

Code:

---

#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;

struct A { int ia; };
struct B : virtual A { int ib; };
struct C : virtual A { int ic; };
struct D : B, C { int id; };


inline bool sortCompare(const D &a, const D &b)
{
        return ( a.ia < b.ia );
}

inline int qsortCompare(const void *a , const void *b)
{
        D d1 = *(D*)a;
        D d2 = *(D*)b;
        return ( d1.ia - d2.ia);
}

int main()
{
        int i;

        std::vector<D> v1,v2;

        D d1;
        d1.ia = 70;
        d1.ib = 70;
        d1.ic = 70;
        d1.id = 70;
        v1.push_back(d1);
        v2.push_back(d1);

        D d2;
        d2.ia = 75;
        d2.ib = 75;
        d2.ic = 75;
        d2.id = 75;
        v1.push_back(d2);
        v2.push_back(d2);

        D d3;
        d3.ia = 65;
        d3.ib = 65;
        d3.ic = 65;
        d3.id = 65;
        v1.push_back(d3);
        v2.push_back(d3);


        cout << " test using qsort() ..." << endl << endl;
        cout << " original data" << std::endl;
        for (i=0; i<v1.size(); ++i)
        {
                cout << v1[i].ia << " " << v1[i].ib << " ";
                cout << v1[i].ic << " " << v1[i].id << endl;
        }


        qsort(&v1[0],v1.size(),sizeof(v1[0]),qsortCompare);

        cout << endl << endl;

        cout << " sorted data using qsort" << std::endl;
        for (i=0; i<v1.size(); ++i)
        {
                cout << v1[i].ia << " " << v1[i].ib << " ";
                cout << v1[i].ic << " " << v1[i].id << endl;
        }
        cout << endl << endl;

        cout << " test using std::sort() ..." << endl << endl;
        cout << " original data" << endl;
        for (i=0; i<v2.size(); ++i)
        {
                cout << v2[i].ia << " " << v2[i].ib << " ";
                cout << v2[i].ic << " " << v2[i].id << endl;
        }
        std::sort(v2.begin(),v2.end(),sortCompare);

        cout << " sorted data using std::sort" << endl;
        for (i=0; i<v2.size(); ++i)
        {
                cout << v2[i].ia << " " << v2[i].ib << " ";
                cout << v2[i].ic << " " << v2[i].id << endl;
        }

        return 0;
}

---

<06 [9:30am] /raid >
<06 [9:30am] /raid > pgCC test.cpp
C++ prelinker: executing: /usr/pgi/linux86/bin/pgCC -c test.cpp
<07 [9:30am] /raid >
<07 [9:30am] /raid >
<07 [9:30am] /raid > a.out
test using qsort() ...

original data
70 70 70 70
75 75 75 75
65 65 65 65


sorted data using qsort
70 70 70 70
75 65 65 65
65 75 75 75


test using std::sort() ...

original data
70 70 70 70
75 75 75 75
65 65 65 65
sorted data using std::sort
65 65 65 65
70 70 70 70
75 75 75 75
<08 [9:30am] /raid >

"Once again my code works, and Philips et al have helped me to verify that it works at least on a number of different platforms. That says enough whether my code is right or wrong."

I'd hate to be the poor developer 10 years down the road who has to wade through your stinking pile of "code". Because it works now, and addresses an immediate problem now does not make it valid in years to come. There will be new platforms and new compilers.

The product I work on has a good deal of history, and so has had its share of "misguided" developers. We've spent a lot of effort cleaning up the garbage. Thier names are remembered, although no fondly.

The issue is not wether your code works or not. From a maintenance standpoint, your code is simply wrong. Since maintenance is the largest cost of software development, this is a very serious issue.

You would not be allowed to write this garbage at my company, or at any company with a project manager worth anything. There's no chance your Qsort would stand up to any code review. Its garbage. Relying on undefined behavior is wrong. It feels ridiculous that I even have to argue such a simple point.

Jeff

Phillips:
I can immediately see two problems in your code, which causes the problem you see on pgCC compiler.

First:

Code:

---

inline int qsortCompare(const void *a , const void *b)
{
        D d1 = *(D*)a;
        D d2 = *(D*)b;
        return ( d1.ia - d2.ia);
}

---

You are un-necessarily creating new objects here, maybe to slow qsort() down a bit to make it look bad? You could have done this;

Code:

---

inline int qsortCompare(const void *a , const void *b)
{
        return ( ((D*)a)->ia - ((D*)b)->ia);
}

---

Second, what causes it fail on pgCC is the third parameter on this line

Code:

---

        qsort(&v1[0],v1.size(),sizeof(v1[0]),qsortCompare);

---

What do you suppose sizeof(v1[0]) to be? Looks to me, v1[0] is a reference to a D object, NOT an instance of D object. Hence sizeof of it evaluate to 4 bytes, which is NOT the size of D object. That's why it fails. You are fortunate that VC interpreted v1[0] differently when it evaluate the sizeof.

Change it to sizeof(D), try again. I am pretty sure it will work then. But let me and others know what is your finding.