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

http://250bpm.com/blog:4

by vq • 11 years ago

122 143 11 years ago

250bpm.com

Todd• 11 years ago

Earlier comments:

https://news.ycombinator.com/item?id=6220049

https://news.ycombinator.com/item?id=3953434

iooi• 11 years ago

And comments to part II (http://www.250bpm.com/blog:8):

https://news.ycombinator.com/item?id=4455225

jsolson• 11 years ago

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 semantics without dumping the genuine advantages C++ brings.

In terms of some of what is brought up in part II, a C++ engineer can (and would) implement linked-lists C-style. See: http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive/list...

rando3826• 11 years ago

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

a3n• 11 years ago

What a strange language, that so much sage wisdom involves what parts of it you shouldn't use. (Former C++ programmer, a long time ago, before the "don't use these parts" advice became a thing.)

dragontamer2• 11 years ago

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

vitaut9• 11 years ago

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.

Shorel3• 11 years ago

C with classes is undervalued, and templates are overvalued, IMO.

Just switching compilers makes the C code more robust.

Retra• 11 years ago

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.

clumsysmurf• 11 years ago

Sometime in the future:

"Why I should have written nanomsg in Rust, not C".

cesarb3• 11 years ago

If you read part II (the link to it is near the end of the post), you see that one of the things he wanted was intrusive linked lists.

From what I have read so far, implementing intrusive lists is not easy in Rust. (If you know of a working intrusive doubly linked list implementation in Rust 1.0 that does not invoke undefined behavior, please tell me; I'd like to know how it should be done.)

kinghajj• 11 years ago

Do you mean "unsafe" instead of "undefined"?

Here's what I found after a Google search, by one of the core Rust devs (unsurprisingly).

https://github.com/pcwalton/multilist

dschatz3• 11 years ago

I have one here: https://github.com/dschatzberg/intrusive

It can be used in a freestanding (nostd) environment such as a kernel. It uses unsafe code but provides a safe interface. The primary technique is to embed the type that is iterated over in a larger struct which contains the links. This way I can give out references to the inner type without fear of invalidating the iterator.

prewett• 11 years ago

He could write his own link list template that only worked with LinkedListNode objects; anything you want to put in the list must inherit from LinkedListNode, which would keep the next/prev pointers. Seems like that would be the best of both worlds.

rkwasny• 11 years ago

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

voidlogic4• 11 years ago

I think that Go approach to error handling i so much better because of exactly the same simplicyty as C.

Not to mention Go having multiple return values IMHO also takes away the major pain point of returning errors in C; using up your only return value and having to take pointer arguments when you would rather not.

cjensen• 11 years ago

Multiple return values is now handled in C++ with tuples and std::tie.

sebcat• 11 years ago

A common way to solve that is to have a function argument point to a place where you want the result to end up, and always return FOO_ERROR or FOO_OK.

i.e.,

    int foo_new(foo_t **res);
    int foo_mutate_copy(foo_t *foo, bar_t *bar, foo_t **new_foo);

Instead of

    foo_t *foo_new(); // returns NULL on failure
    foo_t *foo_mutate_copy(foo_t *foo, bar_t *bar); // returns NULL on failure

I also like the Go way, just thought this way of doing things in C should be mentioned in the thread.

dcu• 11 years ago

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.

tokenizerrr• 11 years ago

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.

dllthomas• 11 years ago

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.

nickpsecurity8• 11 years ago

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 takeup, though, as the technical merits rarely dictate that.

On a related note, I'd like to see the results of it being coded in a modern Ada or SPARK with one of the best compilers. I'd be interested in seeing it with full runtime checks on and off with conservative optimization. ZeroMQ with strong implementation assurance could lay the foundation for all kinds of secure networking and middleware schemes. Heck, I'd like to see a team formally verify a version of it with an executable for common architectures. I'd have fun with that. :)

voidlogic4• 11 years ago

I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game.

Go or Rust? They might not quite match your dream outlined above, but I think in practice they are pretty much used with the purpose of achieving something similar. They both can be "unsafe" as needed and integrate well with C and ASM.

marktangotango• 11 years ago

Vala gets no love in these discussions; a C# subset that compiles to C and gobject.

nickpsecurity8• 11 years ago

Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Rust barely survived some beginner OS projects without its bloat and performance problems showing up. Once comparison I read showed Rust's compiler caught many bugs that slipped through Go's due to Rust design choices. I'm pulling for Rust in particular because its team made clever, design choices for their safety-vs-performance&control tradeoffs. Yet, right now, both are inferior to C, C++, Ada, the old Modulas, and even Fortran for bare metal applications.

So, it's not a dream so much as me wanting to see an excellent middleware implemented in a language proven for decades to do what the two you referenced hope to do someday. Using proven methods, even if ugly or unpopular, is just what engineers do when solving new problems. I'd happily use the same thing built in Rust (not Go as it's less safe) if they can get it more compact and fast. Meanwhile, I have to use C++ and C implementations because that's what's available.

neverartful2• 11 years ago

Objective-C: "You messaged?"

I believe that Objective C is a pretty good (yes, it's getting old) combination of C compatibility with object oriented features as well. The 2 big downsides IMO are: (1) essentially restricted to Apple ecosystem and (2) the syntax keeps a lot of developers away.

QuercusMax• 11 years ago

I agree strongly; I never really mastered C++, but I've done lots of Java development and enough C developments in anger to consider myself at least a journeyman C developer. (I know enough C++ to be dangerous.)

The message-passing syntax is such a funny thing to me; it looks weird, but it takes about 1 minute to grok if you try, and then the rest is very simple. It's really dynamic and lets you do some very powerful things that you wouldn't expect to be able to do in a C-derived language (NSProxy, respondsToSelector:, etc.).

I find it very natural when doing ObjC development to write all my high-level code is very "objecty" style, and then call into pure C methods when I'm doing something tricky/low-level/fiddly.

On the downside, though, mostly due to it being old and not very well adopted, ObjC never got a proper generics system, which is really annoying if you're used to Java or C++.

nickpsecurity8• 11 years ago

My quick perusal of online links show that Objective-C is slower than C++, maybe due to its dynamic typing. It has the C compatibility and basic OOP. Yet, my idea was a language like this which is faster than C++. Maybe a statically typed version of Objective-C would do?

kragen2• 11 years ago

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

nickpsecurity8• 11 years ago

There's no shortage of people taking a stab at language design and even resources to pull it off. The post was intended to provide a simple route for making (a) a better C++ or (b) a ZeroMQ variant with improved robustness & maintenance. Just inspiration and stuff to think about. If I had a budget, a few companies that can get the job done would already have the contract.

girvo• 11 years ago

While it's not a C-like language, Nim [0] is an interesting take on how to do a "systems" language, with a very interesting GC story (and a way to turn it off altogether or manually manage memory when required) and amazing C FFI -- I'm not much of a C programmer, but even I've managed to integrate C libraries into Nim. Still not quite what you're after though; I think more something like Go, with manual memory management would be nicer. A "modern C", that takes learnings from C++'s successes and failures, but keeps C's strengths.

Rust [1], basically!

[0] http://nim-lang.org/

[1] http://www.rust-lang.org/

nickpsecurity8• 11 years ago

I saw it a while back and thought "another toy language that won't deliver." Reading the FAQ, the author quoted as inspiration every alternative language I mentioned in this thread lol. He's done his homework. And the features and compatibility have gotten quite impressive since first release... likely due to him using it to build itself (productivity advantage). And under a MIT license.

I appreciate you bringing it back to my attention. It's worth someone evaluating thoroughly against C and C++ for systems programming (incl OS) in terms of performance and maintenance. Not sure if I can squeeze time in but I'll suggest that to others at least.

Shorel3• 11 years ago

It exists already, only needs more libraries and more users.

Yes, they are removing the GC dependency from the standard library.

TwoBit2• 11 years ago

Nope. The author was just clueless.

derf_• 11 years ago

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.

Daishiman2• 11 years ago

And even so, a lot of very senior C++ users will disagree with the FQA's recommendations.

MaulingMonkey5• 11 years ago

Even though I disagree with many of the FQA's recommendations, at least it describes their rationale. Providing the arguments behind the alternative viewpoint allows for an informed choice.

bkjelden2• 11 years ago

I was really struggling to pick up c++, and when I read the FQA I had a 'it's not me, it's you' moment.

I don't detest the language the way he does, but the FQA really resonated with me. There's no one feature that kills the language, but it seems like everywhere you go you run into a feature that feels like it was designed to trip you up, and it gets tiring after a while.

alexnewman• 11 years ago

He means rust

talles• 11 years ago

Exception throwing is the goto of 21st century. The article's examples aren't the worst, it's common seeing exceptions for business rules in Java/.NET land.

est• 11 years ago

Wat? I thought callbacks are the goto of 21st century.

santaclaus• 11 years ago

I thought plain threads are the goto of the 21st century?

Mikhail_Edoshin2• 11 years ago

Exceptions are just a way for a piece of code to say to its callers: "Sorry guys, this is over my head, I give up, sort this one yourselves." And since most pieces are pretty simple, they encounter these situations routinely. Now, if you want things like nice syntax you positively need exceptions at least as a concept. Otherwise you cannot even add two numbers: take `a + b`, what if the result overflows? What if you write `x = foo(y, bar(z))` and `bar()` fails to deliver? Maybe the try/throw/catch syntax is not that convenient, or maybe the documentation doesn't list all the exceptions that may arise and you feel out of control, or maybe a particular implementation is slow; these are all valid reasons. But I don't see how you can get rid of the idea of exceptions. Well, maybe functional languages have something here, but I'm not an expert in this area; my understanding is that you may define a function as returning either `Error` or `UsefulResult` so you can branch accordingly.

vitaut9• 11 years ago

From my experience, if you need to write many exception handlers then you have a problem in your design as you are using exceptions where you should have used explicit control flow. There is nothing fundamentally wrong with the exceptions and they are used in most modern languages, not only C++.

wvenable2• 11 years ago

I completely agree; the entire time I'm reading this I couldn't help but feel this was misunderstanding the use of exceptions.

The stated design goal is that the project "never fail and never exhibit undefined behaviour" yet exceptions are exactly for undefined behavior. If you can't allocate memory, if your function is called with arguments that it cannot possibly interpret, or that a fully expected network connection has failed and cannot recover. Those are exceptions. For all your defined behaviors, you can control just as described in the article without exceptions.

There is clearly too many exceptions (and handlers) in the first case and way too few in the second case.

kabdib2• 11 years ago

I like Google's guidelines for writing C++. I've worked in a number of groups that independently came up with just about the same subset of C++ (and same set of styles), so those guidelines aren't totally off the wall.

helmut_hed4• 11 years ago

The Google guidelines are... somewhat out of sync... with the intended use of language features as described in the Standard and the recommendations of people associated with it. They seem to take as a starting assumption that the language is misdesigned and major parts of it should simply be avoided or used in unintended ways. If you agree, it's a perfectly fine guide. Otherwise, I'd recommend reading any of Scott Meyers' or Herb Sutter's books and following their advice.

kabdib2• 11 years ago

I've read those books. I have a lot of respect for the authors, and they have a lot of good advice.

But Exceptional C++ made me not want to deal with C++ exceptions, ever. If getting C++ code correct in the face of exceptions is that bloody hard, then the language is broken. I'm convinced that cobbling up an "int" equivalent type that is exception safe is a pyrrhic endeavor that will be a continual source of fragility in production code.

Alexandrescu's Modern C++ Design made me want to forget that templates ever existed. The entire second half of that book I kept saying to myself, "If I'm on a project with someone actually checking stuff like that in, one of us is going to have to leave." Fortunately I've yet to run into those kinds of template metaprogramming games in the wild. Good programmers seem to abhor them.

[Edit: Actually, I remember a bunch of stuff in Modern COM that used templates very heavily. Essentially impervious to debugging; that stuff sucked hard]

More recent C++ design decisions are better than the ones the committees made in the 90s and early 2000s. But the successful teams I've seen all practice restraint and keep things debuggable by limiting the amount of magic going on under the hood, regardless of what the committees have been pushing.

The Google C++ standards (and others that were independently created and haven't been seen much outside their own development cultures) may be "dated", but they remain an indictment of the design of C++.

KayEss4• 11 years ago

This seems to be a failure to understand when exceptions and when error codes are to be used. I'm just starting a big infrastructure project that needs to be high uptime and distributed across a large number of machines, and I'm doing it in C++ because I know I'd never get it working in anything else.

Let's take one specific example -- connecting to a remote host. The loop that goes through the DNS returned IP numbers uses local error codes to try each in turn until one is accepted. If none are accepted it throws an exception so that the higher level application code can decide what to do about the connect failure. The exception ensures that all resources are properly cleaned on the way through.

The exception is used to guarantee that resources are properly de-allocated on the way back up to where the error needs to handled as it cannot be handled locally, probably not in the function that kicked off the connect attempt either, but there's no local exceptions to handle the case where the error is handled locally.

The use of the exception is more like a ROLLBACK on a database transaction together with error reporting -- it helps ensure correctness by backing out properly changes in state that were kicked off by the connect attempt. When the exception is caught the program state is exactly as it was when the connect attempt was first tried so we know we have good clean state to make another attempt or to move on and do something else. Backing out all of these other state changes is really hard when an error code needs to be handled non-locally -- and it's this non-local handling of errors that's so hard and error prone without exceptions.

So if you're only ever using error codes you'll far too easily make mistakes when the error needs to be handled non-locally, and if you're only ever using exceptions then it's going to be real ugly when the error is handled locally.

You need to use both if you want clean code that is going to work reliably (or you need massive engineering resources to fix all of the bugs you'll end up with).

bjourne2• 11 years ago

I think you are right about the author not understanding exception handling very well. But your handling of exceptions is also incorrect. In a fault-tolerant system, dns lookup failures or repeated connection attempt failures is something you design for -- they are not exceptional events.

E.g you have function called connect() then it should return something like a state object with a connection instance or an error indicator such as {err:dns_fail, dns_servers:[..],hostname:".."}

Otoh, if you were writing a one-of script for scraping a web site then you don't care about fault tolerance and then connection failures are exceptional events so throwing on them becomes ok.

KayEss4• 11 years ago

I disagree -- the determinant is about state management and locality of error handling and this is all about how your code is structured, not whether the error is expected or not in some nebulous sense.

If you can handle the connect failure locally (i.e. probably no further away then caller of the connect function) then by all means do so. If you find another structure in your code makes other things simpler, but no longer allows you locality of error handling you should use an exception.

Well designed libraries allow you to choose. Check out Boost.ASIO for an example of this. Every API has both an exception and error handling version and you're free to use whichever is most appropriate for what you're trying to achieve.

This whole thing about 'expected' and 'unexpected' errors is a red herring that leads people down the wrong path.

The exception backs you out of the transaction that your code is performing -- this is the way to think about it. An error code allows you to try something else whilst keeping the transaction alive. Which you use depends not at all on whether you think the error is "normal" or not.

mathgenius• 11 years ago

Yeah, it's a nice example. However, I disagree on the severity of your prognosis.

In C (my preference over C++) I would use an arena memory allocation strategy in this case. This is something I learned from reading the python interpreter source code: when your parser barfs way down in the call stack, an arena is a simple way to clean up everything. (I'm not saying it will be easy in your particular case.)

As for exceptions, you can just use the return value to signal an exception, or if you want to be a bit more radical, use a longjmp.

KayEss4• 11 years ago

The slab allocator is a great strategy, but of course only works for memory, which is really a special case of one out of all of the resources we want to manage. If you're writing long running processes you need to care about any number of file descriptors, maybe mutexes, certainly locks.

You can't bypass all of this in all cases assuming that you only need to deallocate memory. Destructors tidying this up as the exception unwinds the stack is extremely easy to reason about and stops any number of idiotic mistakes.

helmut_hed4• 11 years ago

For anyone who is curious about the intended use of exceptions in C++ I recommend Jon Kalb's two-part tutorial on exceptions from CppCon 2014. First video is here: https://www.youtube.com/watch?v=W7fIy_54y-w

TwoBit2• 11 years ago

As usual, this guy doesn't understand how to use C++. Nobody with any significant C++ experience puts error generating code in constructors. Once I saw that I stopped reading.

Mikhail_Edoshin2• 11 years ago

How does a proper C++ constructor report errors?

maddening• 11 years ago

Several solutions.

First I can think of: don't create situations where error can happen. Compile with exceptions turned off. Out of memory? Terminate the process/thread.

Another: create your objects using some factory, make constructor empty and initialize class by said factory once instance is already created (perhaps recursively instantiating its members). This way all error generating code will be moved outside of constructor.

See how Google approach it: https://google-styleguide.googlecode.com/svn/trunk/cppguide....

yason• 11 years ago

The reason why the charm of C++ wore off on me early on and why C is like my wife who I love more and more each year is that there's a lot of hidden "knowledge" in C++. The language is always playing a game of its own and a lot of your level of expertise depends on how well you've bothered to learn the rules of that game.

For example, exceptions, as decribed in the article. Exceptions themselves make sense in some scope: they model some cases of error handling and controlled longjmping really well while are totally unsuited for other cases where a more fine-grained control of failure is necessary. Thus, exceptions themselves are applicable to an extent in a certain scope.

However, in C++, the scope where exceptions actually do work is even more narrow than the scope where exceptions would generally fit. Like explained in the article, the FQA, and this thread, there are numerous pitfalls where exceptions totally break and a number of assumptions you have to make but can't guarantee. This reduces down to a few "known almost safe ways" of using them with a lot of "ifs" bundled in, and you need to explicitly know those ways.

Unlike in C, in C++ you can't deduce what works and what doesn't out of merely reading or writing code: you have to have enough experience to know these pitfalls first hand so that you know how to avoid them and why. There's basically a line drawn in sand of what is known to work and what is not, like medical remedies in ancient cultures.

And further, all this effort is only really needed to deal with the language itself. It's not required to solve the programming challenge at hand. It's something that is not needed with C because you can reason with C on a "what I see is what I have" basis.

pjmlp8• 11 years ago

"what I see is what I have"

I guess you have not yet seen too much UB or compiler specific semantics then.

zvrba4• 11 years ago

I'm a professional, C++ dev and my greatest quibble with C++ is its deranged system of numerical types, implicit conversions between them, and that signed arithmetic can produce UB just about anytime: http://www.boost.org/doc/libs/1_55_0/libs/numeric/conversion...

pjmlp8• 11 years ago

Mostly inherited from C, actually.

zvrba4• 11 years ago

Well, "defect by design" is still a defect and I have to work around it on almost daily basis. Besides, being able to do (bool+int) could not come from C since C didn't have bool at the time.

EDIT: actually, there are two defects here. One are the implicit numeric conversions. The other one, which causes me most grievance in this context, is that size() on containers returns an unsigned type.

rumcajz• 11 years ago

Author of the article here. Everything said in the article still applies IMO but, to be fair, C misses some useful modern features, most importantly a decent concurrency support. I've recently tried to remedy the problem by implementing Go-style concurrency in C: http://libmill.org

cpp098• 11 years ago

C++ is bad choice for ZeroMQ? Only after he rewrite the code in pure C and run it for years, his conclusion will be persuasive, isn't it?

shepardrtc• 11 years ago

I used to think the same way. In fact, I would reference this article to reinforce my beliefs. But then I actually took the time to relearn C++14 the right way using Stroustrup's Programming Principles book. A project that was horrific in C became ridiculously easy in C++. And I didn't use a single malloc.

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

Related Stories