Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

250bpm.com

Post reply on HN
Print view View original

31–40 of 147 posts

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

#31

Post by cjslep »

tokenizerrr wrote: post #21
dcu wrote: post #15

Earlier quoted context omitted.

yeah go/rust error handling is great. Much better than exceptions which make the code hard to read since you can't easily predict where is the flow going to jump. And the multiple-return is very convenient in this case too. Also, with Go's approach you have to either explicitly ignore the error or deal with it.

My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying. If I'm doing something wrong here I'd love to know it.

The only other idea (and it isn't a very good one) I've seen is to put the error as a parameter and let the called function early return if given a non-nil error: http://play.golang.org/p/bRdFWBZp5r

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

#32

Post by moonchrome »

dragontamer wrote: post #26
rando3826 wrote: post #14

Earlier quoted context omitted.

And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.

Good luck finding a language out there that doesn't have pitfalls.

To be fair I think most languages don't have pitfalls as defaults in the C++ sense :D

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

#33

Post by dllthomas »

rkwasny wrote: post #6

This might be unrelated, but after reading this 3 years after publication I think that Go approach to error handling i so much better because of exactly the same simplicyty as C. ( If you dont’t understand why, dont’t worry it will be obvious to you in 3 years :-)

I like the explicitness of Go error handling.

I don't like that I can't locally hide the boiler plate. There's obviously some measure of essential tension there; I could cope.

I still haven't gotten over the use of product types for return values rather than sum types, and I'm not sure if I will.

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

#34

Post by mtrn »

tokenizerrr wrote: post #21
dcu wrote: post #15

Earlier quoted context omitted.

yeah go/rust error handling is great. Much better than exceptions which make the code hard to read since you can't easily predict where is the flow going to jump. And the multiple-return is very convenient in this case too. Also, with Go's approach you have to either explicitly ignore the error or deal with it.

My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying. If I'm doing something wrong here I'd love to know it.

Sometimes other techniques are more useful.

- you can collect errors in a function and return them once or provide an extra method, like http://golang.org/pkg/bufio/#Scanner.Err

- you can type switch on the error; maybe there are errors that you can recover/retry locally, such as connection errors, or general io failures - so you do not need to pass back all errors to the caller

More on errors: https://blog.golang.org/errors-are-values

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

#35

Post by derf_ »

These and many other pitfalls are all discussed in detail in the C++ FQA Lite:

http://yosefk.com/c++fqa/exceptions.html#fqa-17.1

http://yosefk.com/c++fqa/ctors.html#fqa-10.17

http://yosefk.com/c++fqa/exceptions.html#fqa-17.3

The FQA helped my crystallize a lot of the reasons I hated C++. Even if you like C++, it's a good idea to understand the FQA's arguments, for the same reason people play devil's advocate.

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

#36

Post by vitaut »

rando3826 wrote: post #14
jsolson wrote: post #4

This actually sounds like an argument for why he should've used a smaller subset (or different) of C++. For example: make all constructors private and empty and use public static factory methods for manufacturing new instances. Now the factory can fail, and return an error to boot. Similarly, ditch C++ exceptions and introduce the notion of a status object that methods return. You always have the option of C-style se…

And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.

Actually avoiding C++ pitfalls is not that difficult as most of them come from C: manual memory management, macros, varargs, unsafe casts. In fact C++ provides safe alternatives to many of the unsafe C constructs, so if you stick to them you are fine.

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

#38

Post by kragen »

nickpsecurity wrote: post #7

Interesting article. So, more confirmation C++ is inferior for writing predictable or high performance applications. I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Zero-cost abstractions plus solving C++'s specific problems, painless C FFI, and compilation to C (or LLVM) to leverage their compilers. Might make a nice combo. I doubt we'll see much t…

Is this a sort of informal RFQ? What's your budget?

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

#40

Post by Retra »

jsolson wrote: post #4

This actually sounds like an argument for why he should've used a smaller subset (or different) of C++. For example: make all constructors private and empty and use public static factory methods for manufacturing new instances. Now the factory can fail, and return an error to boot. Similarly, ditch C++ exceptions and introduce the notion of a status object that methods return. You always have the option of C-style se…

You suggestions are great if you don't want to use anything like the standard library or just about any other library. Unless you want to write tons of boiler plate wrapping these things up.
Post reply on HN