[OT] C vs C++

[H. S. Teoh]

On Sat, Sep 10, 2022 at 05:57:53AM +0000, JG via Digitalmars-d wrote:
> On Friday, 9 September 2022 at 15:58:12 UTC, H. S. Teoh wrote:
> > On Fri, Sep 09, 2022 at 09:36:16AM +0000,
> ...
> > 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.
[...]
> In my experience this can lead to, hard to debug code, since the error
> is in the generated code.

In fact, this is precisely the advantage of separately generating the
code: you can examine the generated .d file for yourself and see
precisely what was generated.


> Although of course debugging template heavy or mixin filled code is
> also not a picnic. How do you avoid this kind of  problem?

Template-heavy / mixin-filled code is a nightmare to debug, if they were
not written to be debuggable. Because you cannot see what's the final
code that the compiler compiles.  Whereas generating a .d file as a
separate compilation step lets you examine the file yourself and find
where the bug is.


> For instance if you use, say, vide.d templates, which are an example
> of heavy usage of compile time features, and make a mistake in a
> template you often get a somewhat meaningful error message relating to
> the template file.

That's because the diet templates' code was written to generate these
nice error messages. When you run into a case the authors didn't
anticipate, good like trying to debug the heavily-nested diet code...

Of course, an error in a separately-generated .d file may not be trivial
to debug either, but presumably you also wrote the helper utility that
did it, so by seeing the error in the generated .d file, it would guide
you to look at the section of the helper utility responsible for
generating that bit of code, and you can go from there.


> This would probably be harder  with an external tool (since it would
> have to be able error check arbitrary d).

This is another disadvantage of using templates/mixins: external tools
have to be able to parse templates and magically infer what exactly is
the mixed-in string, in order to help you.  An externally-generated .d
file is just regular D code, you just use standard code utilities on it
and you're ready to go.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill