[OT] C vs C++

[H. S. Teoh]

On Thu, Sep 08, 2022 at 09:15:27PM +0000, Dukc via Digitalmars-d wrote:
[...]
> Going crazy with macros will certainly make C as hard to read as any
> C++.  But I think there may be a point in this otherwise. In C one
> pretty much only has to avoid being clever with the preprocessor, and
> it's hard to totally mess up the readability.

Are you ... *sure*? :-P

Haha, wait till you see some of the C code I've had to deal with.
Somebody, in a glorious fit of NIH, had decided that it was a good idea
to reinvent C++'s OO -- except partially, inconsistently, and without
the syntax niceties and compiler guarantees -- by writing function
pointers everywhere. And I mean, literally *everywhere*: open up a page
of code the code, and almost every line involves at least 1 call to a
function pointer. Most lines contain at least 2-3, some really bad ones
have 6 or more.  Basically, it's trying to imitate C++ polymorphic code
except in C.  But the problem is, since this is all hand-made and not
supported nor enforced by the compiler, the correspondence between
function pointers and logical virtual method calls is not 1-to-1...
meaning that sometimes you *think* a certain funcptr call would go
somewhere, but it goes somewhere else instead, because somebody along
the line decided to "override" it (unofficially) in order to, I don't
know, fix a bug or something.

And being all hand-spun, it's anybody's guess where these funcptrs are
initialized. You don't have syntactic ctors and class definitions that
you can look up to find out; these are all squirrelled away in obscure
parts of the code that, themselves, are chockful of funcptrs leading who
knows where.  Suspect a bug on some particular line of code?  Good luck
figuring out where that funcptr actually leads...  Well, you say, that's
easy, just find out where it's initialized.  OK, so you try to figure
out where it's initialized (hint: it's not anywhere you might imagine,
you have to search long and hard for it).  After you locate the code
that initializes it (by which time you're already tearing out your hair
in frustration), you see that it's also riddled with funcptr calls
head-to-toe, and exactly which value it uses to initialize the original
funcptr is dependent on a whole bunch of other funcptrs that leads who
knows where.  So, to figure out where 1 funcptr leads to, you have to
decipher 15 others.  And each of them, in turn, requires deciphering
where another 15 lead to (because their respective initialization
functions, you see, are written in exactly the same way).

So you can stare at the original function until the cows come home, and
you'd have no idea what it actually does.  Forget about reading the
code; the only way to figure this out is to use a debugger and
breakpoint it, then inspect where the funcptrs actually point to at
runtime.  Trying to decipher the initialization code is like getting
caught in a shark loan: you start out with a debt of 1 funcptr, and you
end up owing another 15, and for each of the 15, you owe yet another 15.
Compound funcptr interest FTW.

Yep, definitely hard to totally mess up readability in C. :-P


> But in C++ there are so much complex features that the code can have
> much worse readability issues than those caused by typical C problems
> (poor naming, no comments, lots of global state, oversized functions).

These are by far not the only problems with C. :-D  (See above. :-P)


[...]
> Maybe the conclusion is that C++ is virtually always better than C in
> itself, but it's use is teached so badly that it often ends up worse.

Um, no.  SFINAE + Koenig lookup.  That combo alone will give you
migraines for weeks, if not months.  No amount of good/bad teaching will
negate the fact that this combo is the stuff of nightmares.  Add to it
mix all the other "niceties" of C++, and ... yeah. Not going there.  I
think I'm suffering from C++ PTSD.

At least in C, once you nailed down that darned funcptr, you *know* it
isn't gonna cheat on you and go on a tryst with a completely unrelated
module that you hadn't suspected was surreptitiously #include'd where
the same identifier was gratuitously reused just to spice up your life.
Identifier hijacking FTW!


[...]
> Since D is a fairly complex language, I think we should talk more
> about when we should avoid the most complex features, such as traits.

One of the things I love about D is: the easier it is to write something
and the simpler it looks, the higher the chances are that it's actually
correct.  (Contrast this with C++, where the simplest way to write
something is almost certainly the wrong way; the right way involves
arcane incantations of black magic that not even seasoned C++ coders
have come to an agreement of which way is actually correct. And the
resulting code reads very much like an undecipherable arcane inscription
reverse-encrypted in Klingon.)

So I'd say the rule of thumb in D is, write it in the simplest way
possible to achieve what you want. If that fails, then consider the next
more complex thing up the ladder of complexity.  Only reach for the
ultimate weapon (did I hear, string mixin? ;-)) when no other recourse
suffices.


> I suspect typical D programmers are not burned by overengineered
> language features as much as C programmers. Don't get me wrong, traits
> are great, but they do have a complexity cost in readability and error
> message quality. Sometimes a less perfect but simpler feature is the
> better choice even in D.
[...]

Agreed.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson