[off-topic] Sony releases PS Vita SDK

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Apr 19 21:41:55 PDT 2012


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.


More information about the Digitalmars-d mailing list