The only way M$ will dominate the market is by a pyric victory, they will have to spend so much money it just isnt worth it in the end.
You know.. I congratulate you for using this word, and for using it correctly! But, I think people would be more impressed if you spelled it correctly:-) It is "Pyrrhic", not "pyric".
You're complaining about people complaining about your complaining...
It's called free speech. Luckily Slashdot (for the most part) allows it here. Just like Microsoft proponents have to deal with Microsoft bashing, Microsoft opponents have to deal with posts supporting Microsoft.
This code as of 11:53 AM on May 1st is clean and safe to use barring somebody modifies it later
<sarcasm>
You insensitive PIG! How dare you assume that we're all in your time zone! You're so timezone-centric. People on Slashdot have got to start being more global. I'm sick of everyone posting things only about YOUR timezone! What about the other 23/24ths of the world, huh??? Bastard!</sarcasm>
Seriously.. just a parody of all the annoying whiners talking about the US-centricity of this site.
Well, we differ there. I would rather have something standard which, given the proper implementation, _can_ be very nice in performance (and, in my experience most of them are faster that I would have written). I like the idea of the interface being known to everyone and being able to buy a fast implementation from someone like ObjectSpace, yet still remain standard. Otherwise, you have all these people learning proprietary collection/algo classes from job to job.
Did you expect them to come out with a spec that says : "When you have a collection with 10 elements or less in it, it must take exactly 12.5ns on a Pentium III 700MHz" ? They can't spec _actual_ performance. There are too many variables. There are also way too many differences in C++ compilers and hardware platforms. That is why asymptotic complexity even exists, so that you can talk about performance of a particular algorithm. It is up to the developer to determine which container/implementation is proper for their particular requirements. It would be impossible to do otherwise.
No big deal. I am actually curious what kinds of things were being done with the strings that made it slow. Of course, things can always be optimized for speed. I'm wondering if the code was just allowing strings to allocate it's pre-determined buffer and grow itself (read: many reallocations and assignments) or whether there was an attempt to optimize within the confines of the STL.
Ok, let me rephrase: (i.e. s/You/The original poster/)
The original poster said "use the STL algorithms only if you don't care about performance". Now, you are backing that up by saying that the "string" class is slow.
We still have the same problem. You were not following the "thread" of the conversation, you were deflecting it to another issue. Thus, your post is off-topic for this thread of the conversation. Your point was valid, just not as a reply to my post.
The standards are not different. There is ONE standard. If you do not like the STL implementation or the compiler's template support on your platform, change. That has nothing to do with the STL. That's like saying Java sucks because Microsoft's JVM stopped at JDK 1.1.4 support!
The performance of STL algorithms is implementation dependent. You get good performance if you get a good implementation and if you use the right combination of algorithm and container. And that means that, for practical purposes, using STL algorithms is risky because you don't know what you are going to get in terms of performance.
I believe that you get more of a performance issue when coders don't understand the implications of writing their code one way or another and use the wrong algorithm to get the job done. It's just like when you hand someone threads in Java. Next thing you know, everything's a thread!
The standard _does_ spec the complexity of the algorithm used, though. I understand this isn't a hard performance requirement, but it's not like you're going to get an O(N^2) algorithm for a lookup on a map, either. You also have the option of switching to different implementations of STL.
The right tool in the right hand is the only good way to get the job done
Do you frequently load massive amounts of strings, then manipulate their contents and leave them in memory? Or are you quibbling about a few K of memory?
...support for templating, across a range of compilers, just isn't very consistant...
How is this insightful?
Just because compiler vendors don't implement the standard properly, this is the fault of the C++ language (of which STL is part)??
That's some pretty broken logic there.
...the STL is, to my mind, just another giant complex wart on top the mind-numbing complexity that is ANSI C++ itself...
This is just blindingly insightful too! This is a flame without even pitching an alternative that solves the supposed problems with STL.
Ahh... Thanks for the clarification.. So, we're kind of both right... It's still MPEG (compressed signal), but the Tivo's not doing the encoding... Interesting.
Slashdot Mirror
Oh wait... actually, it should be United GNU/XFree86/KDE/Gnome/GenuflectTowardsTheFSF/RMS/K itchenSink/Linux
Well, I'll just wait here for that...
You know.. I congratulate you for using this word, and for using it correctly! But, I think people would be more impressed if you spelled it correctly
Your thoughtful spelling police..
T
Alright, so I definitely have a smirk on my face when I say this, but, technically, Linux isn't Unix(tm) either :-)
:-)
In order to be Unix(tm), it would have to be owned by SCO
Tom
Uhh... I guess you're still not sure of it then. (psssstt!! MacOS X is not Linux.... it's BSD!)
T
To those who can moderate (and have a sense of humor), please mod this up! (the parent post)
T
Is that the big bulletin board with the pictures of people and things from the CS department? ;-)
T
It's called free speech. Luckily Slashdot (for the most part) allows it here. Just like Microsoft proponents have to deal with Microsoft bashing, Microsoft opponents have to deal with posts supporting Microsoft.
It's a good system. Why complain about it?
T
<sarcasm>
You insensitive PIG! How dare you assume that we're all in your time zone! You're so timezone-centric. People on Slashdot have got to start being more global. I'm sick of everyone posting things only about YOUR timezone! What about the other 23/24ths of the world, huh??? Bastard!</sarcasm>
Seriously.. just a parody of all the annoying whiners talking about the US-centricity of this site.
T
T
T
T
The original poster said "use the STL algorithms only if you don't care about performance". Now, you are backing that up by saying that the "string" class is slow.
We still have the same problem. You were not following the "thread" of the conversation, you were deflecting it to another issue. Thus, your post is off-topic for this thread of the conversation. Your point was valid, just not as a reply to my post.
T
Now, you are backing that up by saying that the "string" class is slow. That is not the same thing.
Algorithms include things like: sort, find, find_if, partial_sort, count, next_permutation... "string" is not an algorithm.
T
The standards are not different. There is ONE standard. If you do not like the STL implementation or the compiler's template support on your platform, change. That has nothing to do with the STL. That's like saying Java sucks because Microsoft's JVM stopped at JDK 1.1.4 support!
So, what's the problem with the STL string?
I believe that you get more of a performance issue when coders don't understand the implications of writing their code one way or another and use the wrong algorithm to get the job done. It's just like when you hand someone threads in Java. Next thing you know, everything's a thread!
The standard _does_ spec the complexity of the algorithm used, though. I understand this isn't a hard performance requirement, but it's not like you're going to get an O(N^2) algorithm for a lookup on a map, either. You also have the option of switching to different implementations of STL.
The right tool in the right hand is the only good way to get the job done
T
I'd like to see _any_ data to back up this implicit assertion that the STL algorithms are anything but very fast
T
T
How is this insightful?
Just because compiler vendors don't implement the standard properly, this is the fault of the C++ language (of which STL is part)??
That's some pretty broken logic there.
This is just blindingly insightful too!
This is a flame without even pitching an alternative that solves the supposed problems with STL.
T
Being a bit Rogue Wave ignorant, can you tell me what the problem is with "string" ?
How do you know it's Microsoft?
COULD I FEEL ANY FUCKING OLDER RIGHT NOW?
When you were a kid!?!?!
Jesus, I need a beer.
Again, thanks for the info.
T
It works with broadcast fine.
T