3 ms·

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

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.

username223 9y ago
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.
quicknir 9y ago
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).

username223 9y ago

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.

quicknir 9y ago

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