The problem with your statement is that it isn't true.
Selecting code alternatives using #ifdef is one of the benign uses of the C preprocessing feature, exemplifying "use it like this" in contrast with "bad" uses. In many a coding guide you can it recommended to use the preprocessor to do a little #ifdef here and there, while avoiding crazy macros. (Of course, code can turn into a hairball of nested #ifdefs, which everyone rightfully hates, but this sort of use is not characterized with the word abuse. It is just use.)
We could split the function into two copies for those alternatives, put them into separate files and then have something slick in the Makefile to pick the correct file (not the GNU Make ifeq syntax, of course; that would be ironic).
However, those two functions would then contain lots of repeated code also. If something has to change, two identical parts in similar functions have to be updated.
Okay so then we could refactor the function so that all the common things are in a generic part, and then the switched pieces are in a helper inline function (included from one of two different files, etc).
It's not clear that it would improve things in that particular case.
I really have no idea what, if anything, would be worth doing, and that could be due to my mental limitations. If someone sends me a plan about how to refactor that code in a good way (just an outline with bullet points in plain language, no code) I will seriously consider it, and possibly do the work.
Your comment is amusing but otherwise doesn't contradict the claims of parent. Probably better off on a thread discussing parent's tech. This thread is about the Dale language and its implementation. Surely you of all people would appreciate that both should be done with some quality, esp in implementation language. You didn't pick shoddy C++. You went with a language that you thought was better among a number of them. I haven't heard gripes about your code so far so maybe the style was OK, too.
So, your parody is interesting but maybe counterproductive. It doesn't change the fact that the OP is already using language that isn't great for this in a way that doesn't inspire confidence. That's worth noting always as shitty implementations can lead to bugs for early adopters. Best to call out problems in parent's work in threads on that, a mailing list or repo if there is one, etc.
My code is certainly flawed, the question is if it behaves more or less as advertised.
I would be more open to such criticism from users of the software. In my opinion that type of comment is worse than backseat driving, at least in that case the passenger is a stakeholder.
"In my opinion that type of comment is worse than backseat driving"
By that logic, I'd have to lease a mainframe for millions of dollars before critiquing aspects of their offering. Likewise, I'd have to pay Oracle $70,000 per processor. If flawed FOSS, I'd have to go through the pain of setting up and using it instead of submitting the flaw. Your analogy would apply better if you said "person in back seat shouting about an obstacle they're about to hit to driver that fell asleep."
Realistically, though, better to critique than use flawed products unless it gets the job done enough to be worth using anyway. No need to become a stakeholder.
The thing is, I really think that the sort of thing which Dale is is a very, very good idea. Any time I see a link to "C-like language done up in S-exps with macros", I'm very keenly interested, and have all these expectations. I should perhaps do a better job of hiding my disappointment.
Just take this random example http://www.kylheku.com/cgit/txr/tree/rand.c#n138 . The abuse of the preprocessor for checking pointer size is definitely poor practice.
Because of this I won't even bother thinking critically about the language itself. (Though it does make my eyes bleed to read.)
In summary, your comment is low effort, and I hope more people call you out for it.