4 ms·

I hold the exact opposite opinion, and would never want to work on a plain C project. It is so low level that one has to write a lot of plumbing code to take ca

by blub 11y ago

I hold the exact opposite opinion, and would never want to work on a plain C project. It is so low level that one has to write a lot of plumbing code to take care of error handling and resource management. It's also missing pretty much all higher-level concepts that are fast and can make code easier to write, read and less error-prone. Overall, it's simply not fun to write C code, there's a lot of tedious manual work, and even if you do everything according to the book you might oversee something and have problems. Well-written C++ completely eliminates some classes of problems, just like Rust's type system can eliminate even more issues. C is so tedious to write that even if I didn't have access to C++ I would try something else first when the need to write cross-platform/performant code would come. The point is: it's not appropriate to evangelise C (or any other language) without pointing out some of its major disadvantages. This is simply spreading misinformation.

agumonkey 11y ago
Stroustrup gave talks where he explained how to cherry pick c++ elements to decorate simple C code with just enough abstraction to get done safe and fast. I find it's an old timer skill to be able to use languages as suggestions rather than law and to strip it using only the bits that will really bring value to the project.
xamuel 11y ago
>plumbing code to take care of error handling This becomes much simpler once you learn how to write your own variadic functions (it's not that hard, though I do admit it could be prettier). Then you just write one single logerrf function or whatever, which 9 times out of 10 you can carry with minor modifications to your next project. Java does try/catch better in the sense that with checked exceptions you can force library users to at least acknowledge exceptions. Without checked exceptions, try/catch just hides the extra int *err argument under the rug, actually increasing the risk of library users not acknowledging edge cases. >and resource management I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification. The problem is compounded by the way C++ doesn't play nice with gdb/valgrind. Memory leaks and other memory errors are much easier to fix in C than C++. >C is so tedious It really isn't, though, if you use it right. Whatever syntactic tedium it has is more than compensated for by the lightning-fast compile time and the infinitely simpler compiler errors (due to no overloading, no templates...)
- restalis 11y ago
  "I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification." I agree and I want to add that for a language "with a bias towards system programming" C++ makes strange assumptions about the memory. It assumes that there is only one kind of memory available for every operation (and it does its thing with that by default). Then it goes and further assumes that there is only one way (no finer further details whatsoever) of getting that one and only type memory. It's exactly the one boot fits all kind of thinking that Mr. Stroustrup suggests that C++ hasn't.

by blub 11y ago

agumonkey 11y ago

Stroustrup gave talks where he explained how to cherry pick c++ elements to decorate simple C code with just enough abstraction to get done safe and fast. I find it's an old timer skill to be able to use languages as suggestions rather than law and to strip it using only the bits that will really bring value to the project.

xamuel 11y ago

>plumbing code to take care of error handling This becomes much simpler once you learn how to write your own variadic functions (it's not that hard, though I do admit it could be prettier). Then you just write one single logerrf function or whatever, which 9 times out of 10 you can carry with minor modifications to your next project. Java does try/catch better in the sense that with checked exceptions you can force library users to at least acknowledge exceptions. Without checked exceptions, try/catch just hides the extra int *err argument under the rug, actually increasing the risk of library users not acknowledging edge cases. >and resource management I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification. The problem is compounded by the way C++ doesn't play nice with gdb/valgrind. Memory leaks and other memory errors are much easier to fix in C than C++. >C is so tedious It really isn't, though, if you use it right. Whatever syntactic tedium it has is more than compensated for by the lightning-fast compile time and the infinitely simpler compiler errors (due to no overloading, no templates...)

restalis 11y ago
"I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification." I agree and I want to add that for a language "with a bias towards system programming" C++ makes strange assumptions about the memory. It assumes that there is only one kind of memory available for every operation (and it does its thing with that by default). Then it goes and further assumes that there is only one way (no finer further details whatsoever) of getting that one and only type memory. It's exactly the one boot fits all kind of thinking that Mr. Stroustrup suggests that C++ hasn't.