Hacker News Reader

Comment by zanethomas | Hacker News Reader

It's always tempting to use c++ because of, for example, the availability of libraries such as STL and Boost. However doing so greatly increases the complexity of the code, when considered as a whole, and we all know that complexity spins off bugs even in well-tested libs such as mentioned above.

The great thing about C is that when someone shoots you in the foot you know who it was.

View on HN

The big problem with writing a piece of software like SQLite in C++ is that there is generally no easy way to expose a C++ interface to other languages. C++ has too much complexity for other languages to be able to easily construct the data structures it would need to make a function call or handle the results.

The normal solution to this is for C++ libraries to expose an interface in plain C, which is much easier for other languages to call. However, this either restricts what you can do in your implementation (because you're stuck with the C "subset" of C++ for anything near the API), or you have to maintain wrapper code mapping C function calls to your actual C++ interface. Neither is great, so plain C ends up making a lot of sense for a library that is expected to be called from different languages.

This. SWIG is a heroic effort at cross-language compatibility with C++, but it still gets wonky because C++ interfaces are complex, especially when dealing with templates. I still find that the best way to do language bindings is to expose a plain C interface that has no name mangling and treats objects as opaque pointers. Then write or generate bindings to call this interface from whatever other language you're using. Finally, wrap that basic functionality by hand.

SQLite is meant to be basic infrastructure that is wrapped by a variety of other languages. It should have a lowest-common-denominator interface, and C is good for that. And while it might be easier to implement it in $FAVORITE_LANGUAGE, SQLite is mature and well-tested. In some sense it's "finished," and throwing it out and replacing it would be a waste of time.

This makes sense if you are writing an absolutely tiny library where the interface (the surface area) is a substantial fraction of the whole. In most projects of any appreciable scale, the user facing functions and types are a tiny, tiny fraction of the code and complexity of the whole. So no, this argument does not even come close to justifying using C instead of C++.

As few people seem to realize, it's common for even the C standard library to be implemented in C++. Having to implement all of the printf variants (there's 8, I think, at least) using C macros is horrible. Instead, the actual implementation of printf/fprintf etc happens in a function template. You then have one line extern C functions implemented via calling this template, which are declared in the header (and defined in the .cpp, along with the template).

Boost is a technical masterpiece and very high quality C++. It's also battle tested and very reliable. I use it for my professional projects but I loathe using it. Not just the complexity, but the error messages are really hard to decipher and most IDE's autocomplete systems completely choke when using Boost. Even if I want to see how something works 'under the hood' it's almost impossible to figure out.

In the end, I came to the conclusion that it's far more productive (for me atleast) just to stick with plain C and using a 'helper' library like Apache Portable Runtime library.

I wrote some code that was handling upwards of 2 billion qps and every few days it would mysteriously blow up. Fortunately my gut instinct, replacing stl::map with a boost::equivalent saved the day. It's not that I don't have faith in using boost, it's just that I prefer to avoid complication and dependencies when it makes sense.

Yep. I experienced many such situations. Like I said, I still use boost because the benefits outweigh the baggage, but I try to avoid it as much as I can.

btw, 2 billion qpDAY not s :)

> However doing so greatly increases the complexity of the code, when considered as a whole, and we all know that complexity spins off bugs even in well-tested libs such as mentioned above.

do you also take this into account when leveraging $HIGH_LEVEL_LANGUAGE's libraries that are written in C ?

Reply on news.ycombinator.com