111–120 of 141 posts
Earlier quoted context omitted.
Don't use Python. You will produce unmaintainable code that will have to be thrown away in 5 years because it is impossible to refactor.
Interesting. Are you sure it's the language and not the programming style? There doesn't seem to be a reason to prevent you from writing maintainable Python code.
There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've…
On the other side, Rust is a safe language that in real world uses unsafe blocks and unsafe libraries underneath (OpenSSL and other C libraries in practical terms). That is not safe either in practical terms. So there is always this discussion about putting C++ as an unsafe thing and it depens a lot, as you said, on how you use it. I use max warning level, warnings as errors, smart pointers, almost everything return…
All of these have runtime costs. What you describe is C++ forcing you to practice defensive programming in order to avoid costly debugging sessions.
Rust’s borrow checker lets you avoid some of that runtime cost. You can pass around references much of the time without wrapping them in smart pointers. You don’t have to reference count and don’t have to malloc and free as much. And while bounds checking will be on, you can avoid some of those sanitizers too.
You would get this benefit even if all code was unsafe in the libraries that you use, which of course it isn’t.
Earlier quoted context omitted.
Interesting. Are you sure it's the language and not the programming style? There doesn't seem to be a reason to prevent you from writing maintainable Python code.
Reasonably sure. As soon as one of your dependencies gets a major version bump with incompatible API, the clock starts ticking.
Stroustrup as always fails to recognize the vast surface area of C++ features, foot cannons, and the heavy weight of C compatibility around C++ neck. C++ barely made sense in 1995. It makes absolutely no sense today.
I think the funny thing is you no longer even get peak performance from C++. In many ways Java is running rings around C++ performance. Partly, it's because you get state-of-the-art peak optimizations for free from Java, and you'll need a team of 20 full-time build engineers to get a peak C++ artifact with PGO, LTO, and post-link optimizations. Partly it's because the speed of C++ is illusory, with the superficial su…
This doesn't make any sense and nothing in this comment is something an experienced optimizer would say.
I'm not sure where the fantasy comes from that java is going to beat C++, but anyone experienced in optimization is going to control their memory allocations, then control data access being linear so the prefetcher works well, then control memory alignment, then worry about SIMD and multi-threading.
When people talk about optimizing in java, it's usually about turning off the garbage collection, fighting with the garbage collection etc. Memory allocation is trivial in C++ because so much ends up on the stack and preallocating memory is trivial. Java optimization gets stuck on step 1, trying to control memory allocations and pointer chasing.
Show me a program in java and I will show you how it can run faster in C++ (and possibly even faster in ISPC).
Earlier quoted context omitted.
IMO the problem with C isn’t just the horrible standard library. It’s that you can’t make a better standard library — the language constructs needed to abstract almost anything don’t really exist.
The standard library consists many functions that simply should be dropped. All the globals like errno, locale should be removed. Instead of global allocator, allocator struct should be passed around (zig). Headers like stddef and stddint in the standard library should be in the language instead. https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#...
Earlier quoted context omitted.
I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe. basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown l…
> basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown lifetime, and the toolchain does not help track that lifetime. I a decade of writing C++ I never experienced dangling pointer bugs _until_ I started using string_view. Using it safely in multi-threaded environments is damn nea…
Earlier quoted context omitted.
I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe. basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown l…
C++ is safe if you ignore most of its libraries and write everything from scratch, making safety your #1 priority, ahead of performance and everything else, and then doggedly stick to using nothing but the safe primitives you have created.
Earlier quoted context omitted.
I think the funny thing is you no longer even get peak performance from C++. In many ways Java is running rings around C++ performance. Partly, it's because you get state-of-the-art peak optimizations for free from Java, and you'll need a team of 20 full-time build engineers to get a peak C++ artifact with PGO, LTO, and post-link optimizations. Partly it's because the speed of C++ is illusory, with the superficial su…
followed by years of monotonic performance degradation as the flaws in the original are iteratively discovered and remediated. This doesn't make any sense and nothing in this comment is something an experienced optimizer would say. I'm not sure where the fantasy comes from that java is going to beat C++, but anyone experienced in optimization is going to control their memory allocations, then control data access bein…
Most C++ code I have seen does not even approach this level of care and customization.
When we are talking about speed, most people mean basic out-of-the-box speed of the code without heroic efforts. C++ and Java are a wash at this point performance wise. Most analytics code I have seen on Wall Street was either Java or C++, with the choice driven by what the quants wanted in their resume, not performance.
There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've…
Moral discipline means rejecting the use of unsafe constructs for the sake of speed or convenience, and doing the safer, slower, sometimes more clumsy thing.
For instance, to skip thinking like "oh, we can just retain a direct pointer into here, and then we don't need to make a copy ...".
And, of course, while that is all well, you can only practice this advice only applies to small team or solo greenfield projects.