OCCI-gateway, or why C++ is a horrible language
I don't really know to which category this should fit, but I guess "code rant" is probably quite appropriate. I'd like to discuss a bit about why C++ is a horrible language, by adding a few arguments towards Linus.
The exact reason why C++ is horrible for this article is that there's strictly no ABI or even any effort of standardization / specification. In particular, the exception system, the virtual tables, or even the function mangling to embed the argument's types into the symbol's name. That causes a very tedious problem: you can't properly export C++ code into any kind of library.
In plain C, if you export a function, then any compiler around should be able to link to it and use it. The call ABIs in both 32 and 64 bits have been fully specified, and there's no specific name mangling, leading to a clean import of library function to any other software. In C++, because of what I mentioned above, you just can't link anything that's been compiled using another compiler, and most of the time, you can't even link properly with a different version of the same compiler. So in order to share your library, the only safe and clean way to do it is to provide the source code so that anyone who wants to use your code can do it by simply recompiling it for his compiler. If you don't do this, and stick to providing only either static or shared library to your users, there's a high chance tears will be shed.
Here's an example: Oracle's OCCI. This is a quite powerful library that can enable you to access Oracle's databases using a quite clean and powerful interface. Its main advantage (against the existing OCI) is it's written in C++. The main problem is it's written in C++. Because, of course, they won't provide the source code for it. As a result, if you download Oracle's SDK, you'll notice that you have a common library directory with all the dlls, and then you'll have compiler-specific libraries directory containing only the OCCI objects. That's because of the problems I talked above. And of course, they didn't compile their library using every possible combination of compiler. For instance, the AIX version uses IBM's compiler only, the Solaris version uses (sic) Sun's C compiler, and the windows version uses MSVC 8 and 9 only. Note that MSVC10 will not work. It will compile and link though. It just won't work. And most of all, there's no mingw32 version. Bummer.
Which brings me to the main topic of that article actually: OCCI-gateway. This is a project I started and I still don't know if I want to fill it into my (quite large actually) "frankenstein-like experiments" folder, or into the "awesomesause" one. Probably in between. The main idea of OCCI-gateway is to provide the OCCI API to more compilers than what Oracle supports, especially mingw. The way it works is by creating a DLL that I've called "OCCI-MSVCgateway.DLL", that'll import most of OCCI.DLL's features, and export them into plain-C. So if you import this new DLL into your own code, you'll be able to call plain-C functions that'll then translate into C++. From there, there's another .cpp/.h pair that you can import into your mingw32 projet (or probably even MSVC10, but I haven't tested), that'll re-translate all of the C calls into a "OCCI_proxy" C++ namespace. That namespace should contain most of the OCCI classes, that just forward their arguments into the C DLL, transparently making you using OCCI within your non-supported environment.
I don't know if anyone else really tried to do something like this, or if it really had any point of doing this at all. My two main arguments for doing this were "hey, is this even possible ?", (which is the argument that motivates 90% of my projects actually), and the sake of portability for my linux-OCCI code. Now it works pretty well, and it seems other people started to use it. Which is somewhat scary. If I ever see this used into a real production environment, I still don't know if I'll feel shame or pride.