Live data from Hacker News

Why should I have written ZeroMQ in C, not C++ (2012)

250bpm.com

41–50 of 170 posts

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#41
post #30

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…

[deleted]

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#43
post #30

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…

Hm, we must read very different Rust code. ? is even easier than a panic. And that search has a ton of false positives: both in general, as well as "unwrap" being the more common way to get a Result to panic.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#44
By now he probably realizes that the Java version is what he was looking for all along: https://github.com/zeromq/jeromq

Why 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)

#45

Are 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)

#46
post #30

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…

People may do it wrong in rust but I personally like that rust gives me the tools to handle errors in my preferred way: explicitly passing them up the stack with minimal verbosity (using ?) or explicitly having to handle them in some way.

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)

#47

Are 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.

Has it been updated for C++20?

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#48
From Java pro view:

In 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)

#49
post #13

I 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…

> C++ gives you strictly more tools, particularly for guaranteeing reliability, and they're all optional.

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)

#50
Writing in C++ means that the C++ library you are using becomes a dependency. Probably not an issue, if you have the source code to all libraries that you use, but maybe an issue if you are vendor and try to support not only all possible modern compilers, but what they target to (platforms, runtimes, models, etc.)

With 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".

Post reply on HN