Wednesday, February 10, 2010

MongoDB client library: C vs C++

I've been playing a bit with MongoDB recently. Particularly I've looked into source code for client libraries as I was interested in how hard is to change the client API to support async mode of operation. One thing I noticed is that C version of the client library compared to C++ version is shorter and much easier to read. I cannot shake off the feeling that sometimes C++ feels like a step backwards compared to C.

3 comments:

Jonathan Wakely said...

I replied to this post at advogato

Ilya Martynov said...

Jonathan,

I don't seem to be able to reply on your post on advogato so let me comment on it here.


IlyaM, why should you care how long the library code is? What matters is whether the client code is more concise, or more readable, or allows users to be more expressive and efficient.

I have no idea which API is better in that regard, I'm only commenting on your rather misguided measure of how good an API is based on its implementation details. If the two provide exactly equivalent features with neither having any advantage for the user, then it makes sense to question the benefit of the additional complexity in the implementation.


I think you are missing my point. My main point is that there are exist examples when programs written in C when compared to similar programs written in C++ are easier to understand even if they offer similar functionality. Whenever it is some library code or something else doesn't really matter.

I don't think you would argue that easier to understand is not an advantage. I'd like to elaborate that I don't think that it is accidental and that the MongoDB client libraries is not an isolated case. There are other examples, particularly example of libevent vs boost asio comes to my mind. One could argue that if we ignore a number of minor exceptions in syntax technically C is a subset of C++ so it should be possible to write as good code in C++ as in C if not better. My counterargument for this is that C++ in a way spoils programmer but giving him easier tools to build abstraction layers what results in code which is needlessly overcomplicated. On the contrary C programmer not having such tools at disposal must restrict an urge to add additional abstraction layers unless code actually needs then. Complicated programming patterns as simply harder to write in C then in C++ so code end ups simplier. As a trivial example I can think of usage of void* pointers in C for arbitrary data. In canon C++ code similar API would use templates instead to make API type safe. This by itself is ok and might actually lead to easier to use API but once you use templates actively you are on slippery path. We all know how quickly unchecked use of templates leads to incomprehensible mess in code - just look into source code of random boost library.

As for your question on why I would care about library code. Library code is in no way sacred and there are perfectly good reasons to care. First of all one might be interested into adding new features. This is actually the case here: as I wrote in the blog post I'm interesting in adding async capabilities to the client library. Secondly library source code is often much better documentation then actual documentation. And finally reading the source code is the best method to evalute quality of the code what might be a decisive factor in choosing which library to use for a specific task.

Anonymous said...

"adding async capabilities to the client library"

One interesting attempt to do so comes from the G-WAN Web server which does this *automatically* for any existing library used from its ANSI C scripts (servlets, handlers, etc.).

The first (very recent) implementation is not yet bullet-proof (that's experimental code) but at least the method has clear advantages.

Whether or not the library source code is easy to understand (and most are not written to be understood easily), this method will always work without touching existing code.

Plus, writting procedural code that runs asynchronously is a blessing for most of us (especially in the Web scripting or server handlers area).

Keep up the good work: too few decent programmers take the time to express their views -leaving the field wide open to myriads of idiotic posts.