On Thu, Apr 19, 2012 at 10:42:27PM -0500, Andrei Alexandrescu wrote: > On 4/19/12 3:05 PM, H. S. Teoh wrote: > >Yeah, I've been working with C++ for almost 2 decades, and I really > >can't say I'd recommend it for new projects. At my day job, for > >example, we actually migrated from C++ back to plain old C, due to an > >incredibly over-engineered C++ codebase that was slow, bloated, and > >unmaintainable. It sounds laughable to the casual observer, but I > >have to say that there was actually a lot gained by this migration. > >We are much more productive with the new C-based system than C++. > >There are just too many ways to write bad code in C++. C makes > >everything simple and clear, if a bit tedious at times (due to > >basically partially reimplementing a class system in C). > > This is interesting. We use C++ at Facebook all over the place, and > gainfully. If we were to use C, we'd have major difficulties with e.g. > containers. The thought of using a hashtable in C... ouch. [...]
Hashtables in C aren't *that* nasty, if you do it right. (But of course, D's AA's trumps them all, even in its current buggy state.) But I suppose my experience has been colored by the trauma of working with an over-engineered C++ system that only one guy understands, resulting in people who came after him rewriting their own versions of code that they didn't dare reuse 'cos they didn't understand it, eventually ending up in a patch-upon-bandaid-upon-patch codebase with umpteen ways of doing the same thing that *nobody* understands, not even the original guy. One example. The system had this elaborate database abstraction class hierarchy that could do wonders: automatically populate data structures, automatically ensure data consistency, periodically do self-maintenance, replicate itself and sync with backup servers, etc., -- if we only knew how to use it. Problem is, only the guy who wrote it knew which obscure class objects to instantiate to make the thing sing to our tune, so somebody got frustrated and wrote what is essentially a wrapper function that takes a raw SQL string and executes it, thus bypassing the entire beautiful database abstraction code completely. Since everybody else didn't understand the original code either, they started using this SQL bypass function everywhere... only to discover that the system broke in subtle ways when you didn't go through its beautifully over-engineered abstractions. So more and more dirty hacks were introduced that piled on top of each other like festering infected bandages that fail to address the real wound underneath. At the end of its miserable life, the system had places where useful work was done in dtors(!), and was so bloated that the developers of other modules were so scared of linking in the C++ API library that they preferred instead to make function calls to the C++ code by fwrite()ing function parameters into a file, fork() and exec()ing a helper utility that linked to the C++ library, which fread()'d function parameters from the file, then called a library function that then serialized said parameters so that it can do an IPC call to a C++ daemon. The return value of the function took a similar route to pass back to the C code. This was done for *every* function call made from C to the C++ code. My previous supervisor, who was involved in the rewrite effort in C, was so elated when the new system was finally ready and he could go into the source tree and gleefully delete every single one of those C++ files that constituted the old system. I have to admit I shared the same sentiment. (Heck, I could re-checkout the old code and then delete it all over again -- it was that gratifying to see it die an overdue death.) T -- Tech-savvy: euphemism for nerdy.
