[OT] C vs C++

H. S. Teoh hsteoh at qfbox.info
Fri Sep 9 15:58:12 UTC 2022


On Fri, Sep 09, 2022 at 09:36:16AM +0000, Dukc via Digitalmars-d wrote:
> On Thursday, 8 September 2022 at 22:26:12 UTC, H. S. Teoh wrote:
[...]
> > 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.
> 
> I disagree somewhat, because it could be taught that one should avoid
> or be extra conservative with SFINAE because Koening lookup, and many
> other things, tend to mess it up. That's what I meant with bad
> teaching: encouraging to use C++ features which bite back like that.

That's the problem with C++: its features bite back.  What business does
a feature that bites back have in a programming language??  Regardless
of how the language is taught, such features shouldn't be in the
language in the first place.  To shamelessly quote myself:

	A programming language should be a toolbox for the programmer to
	draw upon, not a minefield of dangerous explosives that you have
	to very carefully avoid touching in the wrong way. -- Me.


> > Only reach for the ultimate weapon (did I hear, string mixin? ;-))
> > when no other recourse suffices.
> 
> In my opinion string mixins should not always be the last resort. Sure
> they have the downside that they are essentially macros that can do
> anything.  Walter did wisely requiring the `mixin` keyword when using
> them, so they stand out clearly and are too ugly to be tempting.
> 
> But mixins have the upside that they are much simpler to understand
> than template and trait trickery. That's why a string mixins are IMO
> sometimes better than clever templates.

It depends on the use case.  Templates are much nicer than mixins in
certain cases, but in other cases it may be the other way round.

Hence my rule-of-thumb for D: write the code in the simplest way
possible; when that fails, reach for the next simplest tool.

In fact, in my own D projects I have resorted to external codegen in
some cases, instead of adding yet another layer of mixins/templates to
the code.  Sometimes, it's not worth the extra complexity and
maintenance burden just to have the bragging rights that you did it all
within the confines of the language; sometimes, the more sensible thing
to do is just to write a utility program that generates the desired D
code, and compile that into your main executable.

(Of course, this does assume a reasonably sane build system... if you're
stuck with Certain Hobbled Build Tools *cough*notnamingnameshere*cough*,
then over-complex templates and unreadable mixins may be your only
recourse. :-P)


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win are idiots.


More information about the Digitalmars-d mailing list