Why should I have written ZeroMQ in C, not C++

When people ask me why I stuck with C, it's difficult to give a single overwhelming reason why C is better. The most clear-cut one is that C++ is not supported in the Linux kernel and I want my library to be usable there. But the other reasons why I prefer C are not as easy to quantify.

One reason is that code written in C is more transparent. You can look at some C and know what it is going to do (add some numbers, call a function, etc). Macros are the one exception to this, but good C programs use these sparingly and clearly mark the macro with an UPPER_CASE_IDENTIFIER. C++ is much harder to "see through." Any function call could end up throwing an exception which does a non-local exit from the function. Any addition, assignment, pointer dereference, etc could actually be an overloaded operator. Any function call could be performing a user-defined implicit conversion on any of its parameters. For overloaded functions, the compiler decides what function is actually called by applying non-trivial pattern matching rules. The runtime will automatically invoke any static initialization code (like constructors of global statics) pre-main in an undefined order. etc. etc.

I intend to get a thorough security review of my library once its design stabilizes. I asked Tavis Ormandy (a fellow Googler and security badass) which language is easier to audit for security and he said C for the reasons of transparency I listed above.

People often say that you can just avoid using the parts of C++ that you don't like. That is true, but hard to enforce, especially on a multi-person project. If you're asking others to follow your set of rules, you have to write those rules down in meticulous detail, leading to something like the Google C++ style guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...), and at that point you're asking your contributors to study and internalize a large and complicated list of what is and isn't allowed just for the privilege of contributing to your project. I don't think this approach scales to lots of projects that are all choosing a different subset of C++.

There are definitely things I miss by not having C++'s facilities. Constructors and an implicit "this" parameter are both really nice. Constructors are remarkable in that you can write a single function that gives you three different construction patterns for free (direct construction, heap construction with "new", construction in an arbitrary location with placement new). Automatic upcasts are nice and totally safe. Inheritance and public/private specifiers let you express directly lots of things you can only express with comments in C.

But overall I think that using straight C is the right choice for a project like my library UPB.

It’s the same with any feature of any language. You can choose not to use exceptions in your code, if that makes it easier for you to understand and manage, but it’s certainly not the fault of the feature in general.

Basically, it’s up to you to structure your code well. Yes, it gets bad if a potentially throwing function can be called from multiple points. The error needs to be handled at every one of those points, and probably in much the same way.

But if you see repetition, why aren’t you factoring it? And why are you calling that function from multiple unrelated locations in the first place?

I get it. I’ve used C++ for half a lifetime—it’s a hopelessly broken language. There are tons of things about it that just make me furious. But I can get stuff done in it because I’ve taken the time to understand it in depth. Don’t complain about the language or a particular feature thereof just because it’s not suited to your problem or your way of thinking.

There are other languages out there (Erlang) that are far better suited to stable zero-downtime systems than C++. There are languages (Haskell, Lisp) that help you better manage complexity than C++. Every language implementation worth its salt has C bindings, so you can write performance-critical code at a low level, while still managing the whole system in a high-level language. There are options. Explore them!

We don't use exceptions for the reasons described in the article (and many others), we use boost::system::error_code instead.

But that's for the first half of the article, and the OP admits that he simply gave up on exceptions.

As for the part about half-initialized state, I think the problem is that the author is trying to do OOP in C++ without exceptions. Perhaps a more generic programming approach would solve his "half initialized problem".

Don't want to sound like a snob, but it really looks more like a design problem than a language problem.

Then again, maybe an entirely different language, geared towards high availability, such as Erlang or Ada, might have been a better choice in the author's case.

There are ways that you can use constructors, one way is to have an error-code as part of the object that the constructor can set. Another way is to use the empty-constructor/init-method pattern that he talks about and wrap it in a static method (or function) and that becomes your actual constructor. I think you can even make the constructor private which will prevent accidental calling of it.

But this is just another example of why high-reliability systems require considerably more discipline in C++ than in C, since C++ gives you more rope, it's easier to hang yourself.

There is an argument that such a limited dialect of C++ is so close to C (with a good 3rd party data-structures library) that there is no point to C++ in such situations (which seems to be the point the article is making), and I tend to go back and forth on this.

Just look at all the contortions WinRT has to go through to expose its APIs versus the clean Foundation/Cocoa layering you see in iOS/OS X for a great example.

I would encourage everyone to take a look at the Google C++ style Guide[1]. Most of the complaints are addressed in that article. Constructors can only signal errors through exceptions, so Google C++ allows only basic initialization in the constructor -- all real work is done in an explicit Init() method which can signal an error. I believe the guide addresses the posters other concerns too.

In general, the Google C++ style guideline is a very good resource for writing consistently good C++.

[1] https://google-styleguide.googlecode.com/svn/trunk/cppguide....

Fine to disagree, but respond to the point. So far the relevant objections I've seen are: (a) you shouldn't do anything in a constructor that might fail; and (b) destructors can't fail. Weak. Is there a good counterargument? To be precise: why is the OP wrong to say that, to be strict about error handling, his C++ needs to look like the block of code that follows the sentence, "There's a new 'semi-terminated' state" in the article?

(As for most of the comments, which boil down to "OP is ignorant of basic things about C++ and programming", come on you guys, how likely is that? Who's more likely displaying ignorance here?)

The fact that errors are explicitly returned requires the programmer to explicitly handle them, which encourages design that considers error handling.

The evil of exceptions is they hide errors until they happen.

A fully-fledged condition system (like Smalltalk, CL) would allow for a lot of scenarios where exceptions currently give trouble. They would allow recovering the problem where it happens, retrying operations, and so on. Too bad so few languages have that.

However I don't think the right solution is to use an even more primitive language. C seems simple, but you end up doing everything yourself that would otherwise be done by the compiler, which is a lot more work, bug-prone, makes the code verbose, and generally inconsistent (unless you're very disciplined; forget about it in a team).

here's a rough, probably incorrect demo in python: https://gist.github.com/2653752

gives you nice, clean, exception-like error handling that doesn't leak to the wrong level of the call stack, and in a statically typed language the compiler can verify your error handling for you. quite similar to checked exceptions. call stack issues can be fixed with some low level C, or you could even unwind the stack with some exception trickery.

I've read the Google C++ style guide and it's basically a joke. At least it was a joke two years ago. The guide even contradicted itself in multiple places. Google bends over backwards to avoid using exceptions and the result is that C++ isn't C++ anymore.

http://gcc.gnu.org/wiki/CppConventions

I salute them on following strict coding conventions.

Error handling is a pain in any language. "This thing that should NEVER fail just failed, now what?" If you're not in a recoverable state, realistically, what can you do?

I know that constructors can fail, but it's pretty abnormal for that to happen. I like the way objective-c handles it. Since everything is dynamically allocated and you can just see if the object exists to find out if it works. Lots of methods have an extra NSError parameter that you can use if you need more information.

> There are only two states. Not initialised object/memory where all the bets are off and the structure can contain random data.

He can get exactly the same effect by mimicking fstream interface: use constructors and destructors as they were meant to and introduce bool operator! to check whether the object has been successfully initialized.

In this scenario, only destructor needs to know about the "fail-constructed" state. Other methods don't need to implement the state-machine; calling them on "fail-constructed" object would be undefined, exactly as in his C version (e.g., calling foo_bar without calling foo_init and checking that it succeeded)!

If you have to wonder about what a statement really might mean depending on a bunch of state that was fed to the compiler then that really spoils things.

Not that you would ship ZeroMQ code in it (it's GPL), but still.

Oh, and I love ZeroMQ, and I even love it more, that the "C" interface was the one being public, not the "C++".

Also good article. I love exceptions in higher-level languages - lisp, lua, etc. - but I prefer error codes in lower-level ones, and I consider C++ as such.

which object is he talking about here ? if foo inherits from bar, object foo is not considered a valid object till it's constructor completes. so there is no question of destroying parts of objects which were already constructed.

similarly, during object destruction, as soon as the destructor is invoked, the object is in an invalid state.

i guess there are some issues in understanding of object lifetimes and exceptions thrown by it's constructors...

Granted, exception is problematic. I don't use exception for similar reasons. However, given the nature of this project, it should have been clear that exception should not have been used in the first place. Instead, be very explicit about error handling. This is really a poor design choice. How is it the conclusion that the answer is C, rather than "C++ without exception?".

There is one language/platform[1] I'm aware of designed for this type of system, and which achieves it beyond all others: erlang.

If Uptime is important, how do you handle it when you want to update your software under C++ or C? You have to bring the service down. Erlang supports updating software while its still running.

If exception handling is important (to prevent crashes) how do you handle it when there is a bug? Erlang has supervisors that not only help you manage exceptions but keeps the service going when an unhanded exception causes things to crash.

More importantly, intrinsic to the nature of the way you write erlang code, you eliminate a great deal of the possible errors. In C code you have to check to make sure things are in the right state while running your code. In erlang, your code doesn't run (the function isn't called) if the state isn't right to handle it. It flips this problem eliminating many classes of errors. Further there is OTP support for many types of processing (like state machines) that makes writing these types of solutions much easier.

Erlang is great for making sure no undefined behavior happens. Erlang is also great (as I understand it, this I haven't gotten into) for creating unit tests that can fully exercise the code across all possibilities.

Where does erlang suck? I don't think it sucks anywhere because it has solutions for all of its own problems. For instance, single node performance of an erlang program (which runs in the BEAM VM) is going to be lower than single node performance of a C program... but in erlang you can increase capacity nearly linearly simply by adding more nodes... while this is nearly impossible with almost all C/C++ programs without spending a lot of time working on it.

But where erlang is weak is that single node performance which might be really important[2], and if it is, you can then write your performance critical bits in C.

Thus the things that do the real work can be fast and in C but the things that keep the system going and distributed (where performance of this kind is much less critical, but performance of the operational kind is paramount) can be written in erlang.

So, I think the second mistake he made, and is still making, is thinking that the project has to be written in a single language.

If you use the best language for the job, then sometimes that should mean using two languages right?

Erlang is not a hipster language. No hipsters use erlang. It is 25 years old and boring and %99.9999999 uptime. Its ugly. Its not hot and fresh and new. But it is the right language for the job, when you've got a system that need to run across cores or nodes, or have very high uptime.

And really, it doesn't take but a couple weeks of learning. Then the syntax will be gorgeous and you'll be a better programmer for it.

[1] I say "I'm aware of" for a reason. There may be others as well suited when this is the primary goal, possibly even better suited. I don't know all languages. But I do have a pretty good survey started in the days when new languages were as common as YC batches and much more experimental than they are now. My point isn't to bash other languages but to promote one that isn't understood correctly by many people.

[2] I think this is the case a lot less often than people think. People benchmark things on a single node even when they know they are going to build a cluster of machines to run them, and then pick them based on this. Redis is really fast. Is redis distributed? Riak has a fully distributed in memory database (which means 10 32GB nodes means you can store 320GB in RAM if you want, rather than have 10 nodes all storing the same data in a cache, and thus much less data cached for the same number of machine with something like Redis.