The fear of the misterious

Paul McKenzie said:
>>>>>
Please read what the subject of this forum is:


quote:
--------------------------------------------------------------------------------
Ask or answer C++ questions not related to Visual C++. This includes Console programming, Linux programming, or general ANSI C++
--------------------------------------------------------------------------------
<<<<<

Don't take this the wrong way, Paul, but INCLUDING ANSI C++
does not mean it's LIMITED to ANSI C++. I've been against
Mai's arguments for almost the whole time ... but I feel like you're
stretching here. The only things people shouldn't discuss here
[according to the quote you gave] are questions related to
Visual C++. Again, no offense is intended.

--Paul Wendt

Hello Pau;,

Yes, you're right. However, a Linux and Console program should follow the rules of ANSI C++, just like an embedded C++ compiler subset should follow the rules of ANSI C++ (whatever subset is implemented, it follows ANSI rules for that subset).

My interpretation of the subject matter is that a discussion of compiler specific functions (maybe a Unix "curses" function, or the discussion of interrupt handler functions in C or C++) is allowed here, besides general ANSI C++. Plain, flat-out faulty coding as per language specs shouldn't even be considered, regardless if you are talking about a UNIX fork() function or a Borland gotoxy() call.

Regards,

Paul McKenzie

Hey I totally understand where you're coming from; he's had me
practically ripping my hair out with his seeming stubbornness. I
almost feel like he did a good thing, though; he actually
strengthened my appreciation for C++/STL rather than diminished
it [which I think has been his goal all along]. From where I'm
coming from [24-year old wet-behind-the-ears programmer] it's
nice to see these wild ideas, even if they're totally ludicrous and
ultimately shown to be wrong.

I guess, to sum up, I'm not going to be arguing with you about
whether he should have posted it or not.

--Paul

Paul M.:

Maybe this is for the first time, I want you to quote something from the ANSI C++ standard document to back up your claim. Note, from the the ANSI C++ standard document, not from the words of any individual.

Now tell me, exactly WHICH LINE of sentence within the formal wording of C++ standard says that using qsort() on an object array is prohibited by the standard?

Does the standard explicitly say you can NOT sort integers using qsort()? Does it say you can not sort doubles using qsort(), does it say you can not sort any object using qsort() as long as it contains a std::string()?

For the record, qsort() is a function provided by the ANSI C++ standard library. MSDN said it is ANSI compatible.

And now we are not even talking about qsort(). We are talking about Qsort(), a user written function.

[B]Now tell me exactly which line of code within my Qsort violates ANSI C++ standard?[B] It does not call any function except for the user provided comp() function. The rest is just manipulating and moving chars and integers.

About the only thing I can thing about, is I cast between void and certain data types. You may not like castings like this. But once again, WHICH LINE in the standard document explicitly prohibit casting from/to an object pointer to/from a void pointer?

Technically, my code does NOT violate any of the ANSI C++ standard caluses. You may have an opinion, but opinion is not the standard. Going through the standard word by word, there is nothing that says you can't abanden std::sort and do your own sorting function. Nor does it say you can't use qsort(). Nor does it say you can't cast to void pointer.

OK, now go and find clauses from the standard document before you come back to argue. Don't cite words from opinions of big guys. Opinions are opinions, standard doc is standard doc.

To compiler writers, the standard describes what a compiler must adhere to. To users of C++ compilers, it describes what can be counted on.

It does not describe what can not be counted on. This would be an infinitely long list of items. Obviously, it would be difficult to fit into a document, even using non-standard sized paper ;)

The standard does not tell you how to program. That's not its purpose. It also does not tell you how not to program. That's also not its purpose. Its purose is to provide compiler writers with a precise and detailed document describing exactly what a compiler must provide in order to be ANSI compliant.

The outcome of this? If it is not in the standard, it cannot be relied on. If it is in the standard, it can be relied on. It is as simple as that. Black and white. True and false. Standard and non-standard. It cannot be any clearer than that.

Jeff

Quote:

---

Originally posted by AnthonyMai
[B]Paul M.:

Maybe this is for the first time, I want you to quote something from the ANSI C++ standard document to back up your claim. Note, from the the ANSI C++ standard document, not from the words of any individual.

---

Why not? Unlike you, arrogance doesn't disqualify me from using sources from other individuals, especially experts in the field. Showing you where in the ANSI document has been done by others an umpteen times already. You want me to quote them again? Why? To increase this thread by another 50 posts? I don't have the patience, and from the words of others, they no longer have the patience. If someone were to bring in a neutral party to take a look at this thread, they would say, (as they say in the street basketball games), "you got taken to school." Enough said.

BTW, how is your testing doing with the Pacific Group compiler? Still not working? I wonder why...I wonder if it's that pesky undefined behavior. Bad little buggers, aren't they?

Regards,

Paul McKenzie

Quote:

---

Originally posted by PaulWendt
Hey I totally understand where you're coming from; he's had me
practically ripping my hair out with his seeming stubbornness. I
almost feel like he did a good thing, though; he actually
strengthened my appreciation for C++/STL rather than diminished
it [which I think has been his goal all along]. From where I'm
coming from [24-year old wet-behind-the-ears programmer] it's
nice to see these wild ideas, even if they're totally ludicrous and
ultimately shown to be wrong.

I guess, to sum up, I'm not going to be arguing with you about
whether he should have posted it or not.

--Paul

---

Yes, I believe the same thing -- the opposite effect expected by the OP occurred -- usage of STL has been strengthened by this thread, not diminished.

Regards,

Paul McKenzie

Quote:

---

Originally posted by Paul McKenzie
Yes, I believe the same thing -- the opposite effect expected by the OP occurred -- usage of STL has been strengthened by this thread, not diminished.

Regards,

Paul McKenzie

---

You are right, IMHO. Besides of that, I (and many others probably too) tend to have more faith in what Stroustrup, Sutter et. al. say, than in the oppinion of some individual on CodeGuru. By all respect -- no offense intended. :)

Quote:

---

You are right, IMHO. Besides of that, I (and many others probably too) tend to have more faith in what Stroustrup, Sutter et. al. say, than in the oppinion of some individual on CodeGuru.

---

See what I said before? This is falling into a religious fight. Faith is a word associated with religions. If you believe something or someone by faith, instead of by evidence and reasoning, you are religious. Contrary to what Paul said, I am not going to continue posting on this thread since I have no interest in regilious fight.

I asked Paul to cite the exact clause FROM the standard document to backup his claim that my code "VIOLATES" the standard. He refuses to do so. The fact is he can't. I do things that looks bad in Paul's eyes, I do type unsafe casting from/to a void pointer. I swap objects by direct binary swapping. You may say that's bad, you may say it is unsafe, you may say there may be better solutions. You can say all those because good or bad, safe or unsafe are opinion oriented.

But you can not say that these "bad" things break the standard. No where in the C++ standard prohibits type-unsafe casting. On the contrary, cast operators are specifically INVENTED for the purpose of such type-unsafe casting, i.e., static_cast. Why would static_cast be added to the standard if type-unsafe castings are OUTLAWED?

Does type-unsafe casting break the C++ standard? Paul must think so. Because the only thing bad in my Qsort(), which Paul claims to have broken the standard, is I did type-unsafe casting from/to void*.

Does Paul use void pointer at all? You've got to be doing type-unsafe casting some where, if you have ever used void* at all. So you are breaking the C++ standard right?

The STL code uses fwrite() and a number of legacy C functions underneath, so it calls functions with void* parameters here and there, and some sort of type-unsafe casting is going on there, So STL itself has broken the C++ standard, right?

There is no dispute that The more complicated and time consuming a copy constructor an object has, the more performance advantage you have by using (Q)qsort(), versus std::sort(). The later forces to construct new objects and destroy un-necessarily.

It's ironic that some one cite that std::sort() beats qsort() by some margin when it compares POD data, like integer or double. std::sort() was invented to do "type-safe" sort for NONE-POD data, ironically, that's where std::sort() loses big time to qsort(). I have already shown, in some cases where the object construction involves memory allocation, it loses by being 100+ times slower than qsort().

Is the Portland compiler wrong, or are you wrong?

I'm sure the Portland compiler follows the standard. I'm even more sure that you don't follow the standard.

Quote:

---

cite the exact clause FROM the standard document to backup his claim that my code "VIOLATES" the standard.

---

The standard is not a comprehensive list of what a programmer cannot do. It does, however, provide exactly and comprehensively what can be relied on.

I'm running out of ways to tell you that you are wrong. Well, here's another.

proof:
"direct binary swapping" for non-POD is not in the standard.
-> compiler writers do not have to support it.
-> it may not be supported by a given compiler
-> programmers cannot rely on it to work on a given compiler.
QED

Anyway, let's hear your take on why Qsort does not work on the Portland compiler. Where is the problem? Is it the compiler or your code? Or was your code only intended to work on the compiler you used to create it?

Jeff

So far folks, reports of qsort() working for the Portland compiler are as follows:

it doesn't.

Zeeshan asked this question -- If sorting objects were as easy as the OP thinks it is, why haven't any of the experts done it? Are they naive coders, or is there a reason as to why std::sort works the way it does? Has the OP or any one else pondered that question? Do we have an Einstein here on CodeGuru, and everyone else is a novice? Why hasn't Andrei Alexandrescu (who I believe is one of, if not the best C++ programmer in the world) seen this and written an extensive paper on such a core piece of the library such as std::sort? Why does the head of the ANSI C++ standardization committee point out not to use qsort() in the C/C++ Users Journal article?

http://www.cuj.com/experts/1908/aust...opic=experts#2

It was a recent article, the OP still has time to submit these "incredible findings" to CUJ and have an article posted rebutting the first article.

As Ruslan pointed out at the beginning of this thread, movement of non-POD objects safely involves proper object construction or assignment. Blindly moving objects around, without invoking the proper construction / assigment is nothing but a disaster waiting to happen. This is unbelievable to the OP, since the OP background is 'C'. But this is C++, where rules are to be followed. Again, look at the case of at least one compiler. The qsort() doesn't work, even though it looks like it should work if you look at it in terms of 'C' programming. In 'C', you have no objects, no virtual base classes, no virtual functions, no copy ctor or op= to worry about, so coding like what the OP posts looks fine. Problem is, for ANSI C++ it isn't.

Someone writes a custom copy c-tor and op = for a reason. The reason being that if this object is moved or copied, the contract is that the the programmers routines are called correctly. If you were to write a copy c-tor and op= in the SomeClass, you will notice that it's never called when using qsort(), even though the object has moved. The C++ programmers does not want their objects moved like this (As Ruslan in the beginining of this thread put it, "blindly" copying). Here is his direct quote:

Quote:

---

Third, I want my copy assignment operators and copy constructors
work as intended.
Not blindly copied.
I want members of my class assigned and copied as it were intended
by their authors.
Not blindly copied.

---

With std::sort, the contract is met: the proper c-tor and op = are called for the object when it is copied from one location to another. Without calling the proper construction / assignment, what will happen when you move an object? Undefined behavior. Is this the reason why the writer's of std::sort did things the way they did?

Another point -- std::sort may use a quicksort algorithm (not qsort), but there is no guarantee that it does. There are other sorting strategies that can be used. STLPort uses the "introsort" algortihm. Note the emphasis on "algorithm". All std::sort uses is an algorithm -- it could be quicksort, Quickersort, IntroSort, or some other sort. Improve the algorithm, and you improve std::sort. There is another newsgroup comp.std.c++, where things like this are discussed. The link to the thread that Ruslan provided gives an insight of how careful these people think about topics such as these.

If it were as simple as the OP thinks it is, this problem would have been solved a long time ago and would have been submitted to some organization that has influence. Since it hasn't, again, the OP can do this and be a mover and shaker in the C++ community. I mean, 100x increase? Why keep this a secret?

Regards,

Paul McKenzie

Quote:

---

Originally posted by jfaust
Is the Portland compiler wrong, or are you wrong?

I'm sure the Portland compiler follows the standard. I'm even more sure that you don't follow the standard.
//...
Anyway, let's hear your take on why Qsort does not work on the Portland compiler. Where is the problem? Is it the compiler or your code? Or was your code only intended to work on the compiler you used to create it?

Jeff

---

Don't be surprised if you get the subtlely arrogant response that the "Portland compiler is small potatoes".

Regards,

Paul McKenzie

About Qsort used on Portland Group compiler.

Philips was the only one reporting the problem on portland compiler. And the description of exactly what happened is not clear. And no one else comfirmed that result. Probably due to the fact that maybe Philips is the only one who has a copy of that ***** ****** compiler.

I am unable to comment since I do not have a copy of that compiler, and Philips has not tell us exactly where and how it screw up.

As a long time, programmer, Paul, you've got to know that most time when a piece of code does not work in one spot, the fault is usually NOT at that spot, But some where else that you may totally not have expected. That is why DEBUGGING is more difficult than writting code for most programmers.

If Qsort does not work, you really can't start pointing finger right away at Qsort. It may well be that the code preceeding your Qsort call screwed something up, or that you are not passing the correct parameter to Qsort. There are lot of possibilities that that I can point my finger towards. But I am not going to make any speculation or comment until I see more detail reported from Philips.

Back to binary copying of objects. How many times have I emphasised that I am NOT talking about the broader meaning of object copying in which a new object is created which behaves identically like its original.

I am talking about binary copying in a VERY NARROW CONTEXT, in which we are NOT creating new instance of the object, we are merely moving object around. And further, we are not moving objects to any random memory address. We are swapping, i.e., we are moving an object to a memory location where another instance of the same type of object has previously occupied.

And I have further restricted the usable domain by requiring that the object's state should not depend on its own memory location, but depend entirely on all of it's data members.

In such narrowly defined context, swapping by direct binary swapping should have no problem. It would be interesting to see why Philips's code doesn't work on Portland compiler. But before any one investigate that problem into the detail. No one can really say any thing for sure exactly what causes the problem.

Quote:

---

If Qsort does not work, you really can't start pointing finger right away at Qsort.

---

Well, that makes no sense. If A does not work, don't blame A.

Actually, your algorithm is the first suspect. First of all, there's not much else going on in the program. Second, you're not using a known method/library for sorting. Third, it is complex and largely untested. Fourth, you are relying on something not supported by the standard.

Now what happens? What if it's shown that it really is the fault of your code, and not something else. Will you accept this, and admit that you were wrong? Will you own up to it?

Will you admit that it is dangerous to step outside of the standard?

Or, which is what we all expect, will you blame something else or possibly say that it's not an important enough compiler to consider?

Jeff