3 ms·

>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language woul

by harry8 12y ago

>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way. >That is a surprising statement, especially since you don't necessarily have any idea what my needs are. Look we've probably exhausted this discussion and are talking past eachother, but I do want to point out that this is a simple misunderstanding. I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation." It sounds terribly old-fashioned expressed like this but I guess the meaning is clearer given the way "you" is overloaded to mean you singular (you yourself), you plural (you and your admirers) and you in the sense of 2. here: http://dictionary.reference.com/browse/you http://dictionary.reference.com/browse/you "one; anyone; people in general" I obviously have no knowledge or opinion about choices made specifically by yourself, and we are in total agreement that holding an opinion on such would be ridiculous in the extreme. You might find this interesting, it highlights the problem I'm talking about with exceptions by a guy who has done it in c++ with amazing success, likes the language and appreciates its defects as well as its strengths: http://250bpm.com/blog:4 http://250bpm.com/blog:4 Where you are writing those pieces of code in your program that caused you to rationally choose C or C++ as your language (ie has to perform & caching is important), the STL is a bad option because it wasn't designed for your use, it was designed for everybody's use and you pay for everybody else's use and their architecture choices and so on none of which you are using! So uou pay when you don't use! This is kind of supposed to be what doesn't happen in low level languages. Good C++ code in such a case bears more than a passing resemblance to C and the fact that this is possible is one of the greatest strengths of C++. If you're writing pieces of code that were largely irrelevant in your choice of C++ as a language and if that was the only code you were writing in this project you could have happily chosen a higer level language, the STL is just dandy, use it, write your code fast and forget about its performance as totally uninteresting to your problem. More interesting is where you're not sure, "a deque could be good enough here and will save me time to write." How do you know if it's good enough. Big O don't help you. You should be able to run a canned benchmark you understand on the hardware you're targeting so you have an idea of "good enough" or "won't cut it, need to implement a ring buffer" or whatever. Instead you have to write that yourself or just ouija board. So we duplicate masses of effort from conscientious c++ hackers and simultaneously encourage ouija board decisions. C++ could and should do better. Stepanov's container benchmarks? Is a sorted vector with unique run on it better than a set, ok. Very limited in its general usefulness, for what are supposed to be general solutions. But yeah, about 200 more tests like it for different access patterns, insertion patterns, payload sizes and so on is what is required. Here is Mike Acton (knowingly) wildly overstating the case for audience effect at cppcon last year. On the standards of these lectures this one is an absolute tour de force. Definitely worth your and any C++ hacker's time. Look up Alexandrescou's lecture on optimisation at the same conference as a benchmark to see just how good it is. https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc

maxlybbert 12y ago
>>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way. >> That is a surprising statement, especially since you don't necessarily have any idea what my needs are. > Look we've probably exhausted this discussion and are talking past each other, I agree, it's petered out. > but I do want to point out that this is a simple misunderstanding. > I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation." I prefer "you" over "one." And, for the record, I didn't take it as an insult. But I find it odd to believe that the only reason anybody would use C++ is for performance. That there couldn't possibly be another use case (or if there were, it would be incredibly rare). I guess the only reason somebody would pick Python would be a strange obsession with whitespace? And Java's only for people who like checked exceptions?
maxlybbert 12y ago
I had looked at using ZeroMQ for a project. Based on the deep misunderstanding from that blog post, I'm glad we didn't. First, undefined behavior has an actual meaning in C++, and it's not "nondeterminism" ( http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... ). Second, if you're going to publish a library, it's certainly important to have an error handling policy. But I find it very strange to assume that your clients will screw up error handling and blame you for it. The blog post doesn't say this explicitly, but I think it's the source of the "no exceptions, ever" policy ("no exceptions, because the clients will screw it up"). Third, you shouldn't throw exceptions for every error. You throw exceptions when something went wrong and you don't think your immediate caller can do anything intelligent about it. If the immediate caller can do something, you return an error code. Fourth, did you know that printf() can fail? What should you do if it does? You can't print a warning to the user. Did you know that closing a file can fail? What should you do? Close it again? If a destructor is unable to clean something up, it's basically impossible to do anything about it. You might log the error, but I don't see what you'd do about it.

by harry8 12y ago

maxlybbert 12y ago

>>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way. >> That is a surprising statement, especially since you don't necessarily have any idea what my needs are. > Look we've probably exhausted this discussion and are talking past each other, I agree, it's petered out. > but I do want to point out that this is a simple misunderstanding. > I meant "you" in the sense of the archaic english "one" "If one uses C or C++ and one does not care about performance one has performed a premature optimisation." I prefer "you" over "one." And, for the record, I didn't take it as an insult. But I find it odd to believe that the only reason anybody would use C++ is for performance. That there couldn't possibly be another use case (or if there were, it would be incredibly rare). I guess the only reason somebody would pick Python would be a strange obsession with whitespace? And Java's only for people who like checked exceptions?

maxlybbert 12y ago

I had looked at using ZeroMQ for a project. Based on the deep misunderstanding from that blog post, I'm glad we didn't. First, undefined behavior has an actual meaning in C++, and it's not "nondeterminism" ( http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... ). Second, if you're going to publish a library, it's certainly important to have an error handling policy. But I find it very strange to assume that your clients will screw up error handling and blame you for it. The blog post doesn't say this explicitly, but I think it's the source of the "no exceptions, ever" policy ("no exceptions, because the clients will screw it up"). Third, you shouldn't throw exceptions for every error. You throw exceptions when something went wrong and you don't think your immediate caller can do anything intelligent about it. If the immediate caller can do something, you return an error code. Fourth, did you know that printf() can fail? What should you do if it does? You can't print a warning to the user. Did you know that closing a file can fail? What should you do? Close it again? If a destructor is unable to clean something up, it's basically impossible to do anything about it. You might log the error, but I don't see what you'd do about it.