4 ms·
>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 d
by 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.