Skip navigation

Tag Archives: C++

It has been almost ten years since I wrote that other blog post. The reason why I wrote that post in the first place is a mixture of self-therapy, the need to tell the rest of the world, and also as a tribute to the people who shared that ordeal with me. I can attest that everything written there is true, and I have not (yet) shared everything there was to say. Tons of other anecdotes come to mind, but this is a period of my life I wish I could just erase.

When I first released that post, I received dozens of private messages from all over the world, from people telling me they clearly recognized their own project and I should not have modified it to make it look like it happened in France. That was probably the craziest part, discovering that hellish projects like this one must have repeatedly happened for years. In case there is any doubt: yes this happened in France, in the North of Paris, in a company best known for selling all kinds of stuff you wish had never been invented. Do your research, I am not telling.

This is not the worst project of all, to be honest. Spend a bit of time on the daily WTF if you want to get your fair share of software engineering shittiness.

My takeaways? C++ is a disaster, but I already wrote another post about that. CORBA deserved to be killed in flames. Object-oriented databases were always just a very bad idea. But what made this project hell was the sheer stupidity of the managers. Coluche once said (about bankers): give those guys the Sahara and in a year they will tell you they need more sand. Apply the same thinking to software project management.

Anyway, I was told a couple of years later that the main project boss had ended up in jail for fraud (détournement de fonds publics), so maybe there is a justice after all. I never confirmed that news but have all reason to believe it is true.

Seems somebody has posted a link to that other blog post on reddit a couple of days ago, which explains the sudden spike in views. Here are the links I found:

On reddit:

And on twitter:

Among the many comments, some surprised me. Seems lots of people cannot believe you can be fired in France for being 1 minute late at work. Sorry to burst your bubble, mates, but this is what SSIIs (contractor companies) were invented for. You don’t lose your job, you immediately lose the contract you are working on (no justification needed, this is what contractors are for), end up between four walls at the contracting company, and then you are told your job is not justified by the activity level. Question of weeks before you lose your job then.

Here is a link (in French) to a judgment about a contractor company who fired someone for not accepting a contract. Two years in court for 30k, probably not worth the effort if you ask me. But then, most people won’t even try to sue.

For people who have a direct contract with the company, same story. Nothing prevents the company from saying you have committed a major blunder, fire you on the spot, and see you a couple of years later in court (Prud’hommes). Yes, that will cost them money if people choose to sue (I hope they all did). When you are unemployed, are you really looking forward to two years of battle with your former employer, even though you know you will win?

Let me give you a hint: the same company fired an employee for wearing shorts at work. That employee sued and won, but the no-short policy was established.

Don’t tell me France has good employee protection, this is just not true.



Usine a gazSo here we are: it is 2008 and some people out there still think C++ is a neat idea. To the point that the latest Stroustrup interview shows him confident about the future of his pet language and it seems nobody has told him yet.

So what grudge could anyone possibly have with the language that gave us most of Windows, Photoshop, KDE and Microsoft Office? Before you pick up the flamethrower, let me detail things a bit.


Complexity is a key issue. Initially designed by a single man or small group, the language has grown by accretion over the years and suffers the dreadful “Design by committee” feature that gave us e.g. CORBA. If you have any experience working with C++ you know what I am referring to: you have spent countless hours learning how to use such or such feature, doing the exercises, practicing on tiny meaningless projects where everything is clear, and suddenly you are faced with a pageful of code where nothing makes sense. Nothing. You grab that book again, go through all the details and cannot find what the hell is written on screen. You know it compiles, even if the compiler swears at you in Russian, but you still do not know how. And you will never know.

In Effective C++”, Scott Meyers warns about the many sub-languages contained in C++. He mentions C, Object-Oriented C, Templates and the STL, but if you look closely there are about as many flavours of C++ as there are compiler vendors, multiplied by the number of platforms, multiplied by the number of programming rules and recommendations, multiplied by the number of active programmers. On top of that, the ISO committee releases new versions every now and then to spice it up. Faced with such a huge mountain of complexity and sub-dialects to learn, the only sane reaction is to focus on a smaller number of topics and try to master them inside out until you feel confident in your programming skills. The best C++ gurus I have ever met admit they master around 90% of the language, which is quite sufficient for them to produce their share.

As a Project Manager, you are given the task of producing a quality piece of software to fulfil a number of objectives. You have 10 expert C++ software engineers ready to work for you, what could be better?

As it turns out, chances are that the 10% C++ slices of ignorance for each software engineer do not overlap. This will translate to parts of the project that can only be maintained by one programmer. If the guy leaves for any reason you are hosed. Nobody can read or understand what was written so you end up re-engineering parts of it, finding workarounds, encapsulating the working parts in something you can actually understand and maintain.

This is still rather theoretical so let me pour some more reality. As much as it saddens me to say it, I have no Nobel Prize in computer science and neither do most of the programmers I have been working with. C++ complexity is just out of reach for most engineers I have met, whether they wanted to admit it or not. This should not be an issue because after all, we do not write programs to please a compiler but to achieve a goal that is in one way or another related to humans and their well-being. I believe a good software engineer should be able to design a useful system no matter what language is used for the implementation. What I observed was just the opposite: after a few months working on a C++ project, we realized that we were spending more time fighting the language and the compiler than actually implementing something useful. Bring in enough C++ experts and witness endless sterile discussions about copy constructors and inheritance when we should have been talking about usability, feature enhancements or backward-compatibility for old data files.

We should not have to think twice when using a tool. The more we need to think, the less we are able to actually use the tool for anything useful. I have seen too many projects caught up in the web of C++ complexity, where the main activity seems to be sheer survival against the language.

Binary (in)compatibility

Second issue: binary compatibility (ABI). The way C++ objects are named in an object file has not been standardized until quite recently. Until then, it was just impossible to link two objects produced by two different compilers. This may not seem too important at first, but let us review the consequences:

You cannot link your code against a binary-only distribution of a library.  For library vendors, it means you will have to release the source to your code or die. This may seem like a good case for open-source addicts, but in many cases a binary release solves a lot of issues.  Integrating a third-party library as source code means you have to bring in all the needed compilation environment, which may or may not be compatible with yours. Your problem was to integrate an external library, now you need to figure out how to compile it too.

The next consequence is more dramatic. Imagine you write an OS in C++, where all base libraries and system calls are C++ objects. Since you cannot mix objects compiled from different compilers, you will be locked into a single compiler for your system, and this also holds true for all developers working for your OS. Single point of failure: the whole OS future is tied to what was initially a developer tool to transform C++ into assembler. Microsoft has found a workaround by declaring all Windows interfaces using C constructs to avoid locking all Windows developers into one single compiler. More than technical reasons, this would probably have been the cause for European Union (rightful) accusation of monopoly.

You may well say that this drawback is something of the past now, and I would like to believe it too, but I see too many old systems still being used in production all over the place and they all have issues with C++ compilers due to ABI incompatibility. It may take decades before the problem goes away.

The very fact that it has taken all these years to come up with a unified ABI seems to hint about the nature of the C++ standardization committe talks: vendors lobbying to protect their interests, rather than computer academics talking about pure ethereal concepts. I was not there but that is what it looks like seen from the outside.

That may be right for others but not for me

As a single programmer, you may not have realized that limiting yourself to a subset of C++ could have consequences. You feel talented at what you do and you certainly are, but the issues come when you start working in a team, i.e. any decent-sized project. You may have been bitten by binary incompatibility and you may think that is something of the past now. If you are lucky enough to only work on brand new projects working on future OS’s, keep your head high and ignore the argument. For all other people living in the present, you have my sympathy.

Another thing I used to hear was: “if C++ is so bad, why is everybody using it?”. This was 10 years ago. Today, most software engineers I know would not touch the thing with a 10-foot pole. Judging from what you can read on Slashdot any time C++ is mentioned this seems to be a largely shared opinion. Though the discussions tend to end up in the usual flamewars, many raised arguments run very deep. Pick any recent discussion on the topic and check by yourself.

If there was no other choice of programming language we would all probably figure our own way out, but today we have many more languages that are all better adapted for the task and do not force us to take this kind of unneeded risk on our projects.

So go ahead and flame me. This will not change what my eyes have seen over the last 15 years in many, many different projects taking place over different countries and businesses.

Relevant links: