Earlier quoted context omitted.
> there will always be a case where you forget to propagate an error you got Not if the ecosystem supports Result types a la Rust (and others). You don't get to access the return value unless you deal with handling the error first.
> You don't get to access the return value unless you deal with handling the error first. Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site, so from what I could see, either people end up doing nothing and "abandoning" the error (bad) or panicking (worse). It's better to just let the error go transparently so that if someone actually ca…
Why should I have written ZeroMQ in C, not C++ (2012)
41–50 of 170 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#42Re: Why should I have written ZeroMQ in C, not C++ (2012)
#43Earlier quoted context omitted.
> there will always be a case where you forget to propagate an error you got Not if the ecosystem supports Result types a la Rust (and others). You don't get to access the return value unless you deal with handling the error first.
> You don't get to access the return value unless you deal with handling the error first. Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site, so from what I could see, either people end up doing nothing and "abandoning" the error (bad) or panicking (worse). It's better to just let the error go transparently so that if someone actually ca…
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#44Why C/C++ coders don't even write "Hello World" in Java SE before drifting away into rewriting the ball bearing (1907) part of the wheel is beyond me.
The Throwable class is exceptional in every way, it wastes almost nothing and gives the programmer the ability to catch all problems that occur in the VM.
public static void main(String[] args) {
while(1) {
try {
// do everything, and always throw unchecked
// Exceptions unless you need the programmer to
// handle the problem
}
catch(Custom c) {
// here we can react to the exact problem the
// parent programmer devised
}
catch(Exception e1) {
// something "normal" happened that would have
// generated completely random behavior with
// machine code
}
catch(Error e2) {
// something "critical" happened that would have
// generated a segfault with machine code!!!
}
finally {
Thread.sleep(10);
}
}
}
The above code will never cause you to loose sleep. You can pretend there is a way to do this in any other programming language, but only C# would be able to and it is lackluster in so many other domains.C will not help you with exceptions or concurrency, it will punish you into believing Rust is the solution.
C++ Exceptions are complete garbage, the only good part of C++ are std API (not implementation apparently) and Objects for structure, not for data (cache-misses).
Java does not crash and has the same performance as machine code, that is why it is the leading server language in the world.
Goodbye karma! Xo
Edit: that was fast!
Edit2: Please comment if you downvote.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#45Are there any good resources (websites/books) to learn some of the new ways of doing things in C++ 20 vs older. Eg something that shows the old patterns with pitfalls and what replaces them in C++ 20?
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#46Earlier quoted context omitted.
> there will always be a case where you forget to propagate an error you got Not if the ecosystem supports Result types a la Rust (and others). You don't get to access the return value unless you deal with handling the error first.
> You don't get to access the return value unless you deal with handling the error first. Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site, so from what I could see, either people end up doing nothing and "abandoning" the error (bad) or panicking (worse). It's better to just let the error go transparently so that if someone actually ca…
I don't like verbose error checking on every function call which is ugly and which I might forget to pass up (c-style) and I don't like exceptions which aren't expicit and which I might forget to handle locally if I wanted to.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#47Are there any good resources (websites/books) to learn some of the new ways of doing things in C++ 20 vs older. Eg something that shows the old patterns with pitfalls and what replaces them in C++ 20?
Bjarne Strsoustroup's short book "A Tour of Modern c++" fits the bill, and was written for the same purpose.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#48In Java it's a sin to do anything complex in constructors. You only assign fields and maybe, maybe, call some pure static function to assign a computed field.
That mainly comes from unit-testing perspective -- so you can mock the parameters for a unit object _before_ the object does anything.
If you really need to do something complex to initialize those fields, it's better to extract them to different service class (and call it, ahem, Factory).
So the code looks more like his C example, but wrapped in classes.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#49I was trying to figure out if this was satire. C++ gives you strictly more tools, particularly for guaranteeing reliability, and they're all optional. What particularly laughable here is the split ctor/init pattern is allegedly driving them towards C, whereas C doesn't even give you dtors! If you're forgetting your init calls, are you really telling me you're not going to forget your destructor call? There are plenty…
You are right. But it doesn't help. When I used C++, I constantly shot myself in the foot by using its features. It did not feel like overusing, but I just wanted type-safety and to replace macros. It was impossible to restrict to useful features, because they are all useful in their way, only they come at the price of spreading everywhere until you don't understanding what is going on. Typing rules are insanely complex. Overloaded template error messages and hilarious amounts of boiler plate member functions just to satisfy the constructor rules and to catch the best overload for every integer type were the result.
I went back to C. It's a relief.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#50With just "C", not "C" only at the interface part, you can avoid that. Even to the point that your binary artifact (library) can be reused safely between DEBUG and RELEASE. Alternatively you need to ship this as shared statically linked to CRT library (which lots of vendors do), but it's general pain in the ass... for all platforms.
So that is the hidden cost of C++, even if your interface is still "C".