Hi galathaea,
I'd like to say first, that I really don't feel that this is going anywhere. I generally don't like to read a 2 page post to weed out a few points. In my opinion, the major problem in this thread is that there are lots of statements and yet not a lot of backup. Everything that I have stated can simply be proved or disproved by opening your compiler and writing a few lines of code to see whether what I have said holds true. That is why I have asked repeatedly for anybody who doesn't believe anything I've said to just try it. Stating that I am wrong with nothing to back it up but 2 pages of opinion, I feel, just wastes time.
But nonetheless,
Quote:
Actually, I really don't want to bring Darwen into this issue, because from the general quality of his posts, I have no doubts that he will eventually have to confront the standard containers head-on through some reason or another, and I think that after the first few test programs, he will finally have those epiphanies on why their structure is the way they are and not think twice about them
This is what I was talking about in my last post. You are assuming that Darwin just doesn't understand STL. "He will eventually have to confront the standard containers". He has, and he has said no. "after the first few test programs" is the exact kind of statement that causes this to go on and on.
He said, "I actually know both the STL and MFC very, very well having used both for a large number of years and prefer MFC.
" at his 5th post and he has constructively dissected STL through out this thread and made many valid points. Are you calling him a liar? He gets the same "you are wrong" response repeatedly through out the thread. And example would be Paul's response of "Looks like your trolling. ".
Or perhaps comments like this, "If you're going to talk about something, at least know the topic well enough to comment.".
Or this, "No I don't see what you mean, you don't understand the CRT at all, so your lack of understand leads you to this"
This is just a handful of comments the first dozen posts to Darwen.
Darwen on the other hand, asks lots of questions in his posts, and the usual answer is, "you just don't understand", or comments as you have responded above.
This is not the makings of an intelligent debate.
In my opinion, when a response is one of a simple, "you are too stupid to understand", then the person who said it probably doesn't understand himself. No matter how complex he writes his reasoning.
This is why the STL crowd hasn't proven or settled their argument. The only person who has actually done anything to support any thesis was Yves by writing some code and actually testing it. Granted his library was giving him some grief, but he actually attempted to prove his thesis with code. That is debate. When you say to someone, "try this and you will see for yourself", you are persuading someone, when you state, "you are wrong because you don't understand", then you prove nothing and show a lack of understanding yourself.
So Darwin is key in this debate. To say he "just doesn't understand" is to show that the lack of understanding is on your part, not his, in my opinion.
Quote:
Actually, "ugly" is not a particular at all, and "difficult" equates to me to "i have yet to learn this"
Various bits of STL have been posted and if you feel that someone's dislike of one letter variables means that they "have yet to learn this", then I think you have yet to learn about good design.
No programmer worth anything would ever say that one line functions, and uninitialized variables, and one letter names are pretty coding. Any well written program should read as easy for another programmer as English. If another programmer has to walk around your code trying to figure out what is what, then you have written your code poorly and in most production environments you would be warned then fired for such poor produce.
Quote:
The same mistake was made with the entire misunderstanding between vectors and lists in this thread that prompted this entire diversion
Something that I said at page 8 hardly qualifies as the reason for the STL division. I don't think you realize how long this thread is and when I got involved.
Quote:
You see, contiguous addressable memory refers to the fact that locations in the container can be referred to with pointer arithmetic without traversal
Of coarse, that is the definition. But the one problem with your statement is relativity. While it may indeed appear to be "contiguous" to your program, it may not be to the system. Which again is why I have provided several links to help explain that. Which bothers me that you feel that I don't understand what the difference between a linked list and an array is. But the misunderstanding is on your part, because I'm talking about how the system is handling your "contiguous" memory and you are talking about C containers. Which is another misconception in this debate. There are no rules when it comes to containers. Nothing says that a linked list has to allocate memory at each insertion. You can do the work wherever you choose. You can allocate yourself, or let the system do it for you. The same goes for vector. However, you should understand what the system is doing before you choose to use a method. So I would recommend you read the documentation in my last post so you can understand a little better what I am talking about.
Quote:
suggest turning off exceptions and building a program that tests every allocation for NULL return errors and see what runs faster.
I will indeed do this, when you have time, could you please show some code and statistics for what you believe is faster and slower so I and others can see what you have seen that makes you believe this?
Quote:
I know that when one feels they are being attacked, it is quite natural to jump back with proof that they really are special, even if it means changing the topic to something they know a bit better, but that is all that it was (topic changing).
Talking about STL's performance is very much on topic. Talking about how the system functions in relation to difference access methods which relate to STL is right on topic. To suggest to write code and test its performance, is not only on topic but a good debate method. So I don't see why you feel a topic change was occurring.
Quote:
In other words, no matter what occurs during the dereference operation, the vector has the advantage in the move
unless of coarse the list simply has to dereference a pointer to its element with out any calculation...or if the list managed its memory in succession in which case it could perform the same move as the vector...in which case it would be just as fast...I guess it all has to do with how the class was written. Which would go back to the design issue, can another programmer make more efficient class then the STL programmers, or are the STL programmer’s programming unsurpassable?
Quote:
What I think that discussion has shown, however, is that intelligent people can mistake the concepts embodied by the standard containers, attempt to hand-roll one type and mistakenly produce a different one with different complexity guarantees, without the abstractions built in, and that this example pretty much underlines the point I and others have been making all along.
I feel the argument has shown that there are too many "die hard" STL users who believe that STL is a "holy-grail" and when confronted with this, its stated that all who oppose it, just doesn't understand it. Many of us old-timers have been writing container classes long before STL and those who have written them understand how they work, how they perform and how they are adaptable, they understand this because they themselves had to do the work, something I feel that those advocating STL haven't done. STL was designed to be a quick and dirty container solution for programmers who needed it, just like Visual Basic was designed to make quick and dirty windows programs. So because of this, I feel the points are moot.