in reply to Introducing the C Perl-Powered Pre-Processor

Love the Spinal Tap reference in the doc!

With EUMM, you can already do this with PL_FILES. And really, using Perl to generate C is PDL's whole thing, so you could use that?

Replies are listed 'Best First'.
Re^2: Introducing the C Perl-Powered Pre-Processor
by NERDVANA (Priest) on May 13, 2024 at 16:59 UTC
    C code is just text, so there are infinite ways to use Perl (or any other language with a print statement) to generate C code. The point of cpppp is to have templates that are fairly readable as C code, and output that is good enough to commit to a repo, and a collection of tools that meet common needs in authoring C. These things can be fairly awkward to do with plain old print statements, or even Template Toolkit. And, maybe more to the point, they're painful to do with C's own preprocessor, which was designed specifically for this role, and especially painful to handle with the C++ template system, which was designed to make up for the shortcomings of the preprocessor and yet still falls short, in my opinion.

    Now, sometimes it looks OK to just use here-docs. But with more advanced cases it can get rather ugly. It can even get ugly just using C's preprocessor in a pure C project. I haven't gotten around to rewriting those in cpppp yet, but I assure you it will be more readable.

    If you have examples of PDL making life easier in this manner, I'd be interested to see them.

      That "rather ugly" one looks actually quite neat!

      I was over-egging the pudding a bit, for humorous(?) effect. Within the PDL-o-sphere, its DSL makes it quite close to fun to write n-dimensional loops. It has some slightly deranged, borderline "cpp abuse" levels of macro to generate per-supported-type code within proper C code (PDL_GENERICSWITCH et al if you're interested), and PDL has infrastructure to generate one version of given "code" per supported type.

      The above results in something a bit like, but more deranged and worse than, https://github.com/rofl0r/order-pp/blob/master/example/array_ops.c

      I keep thinking that there are various parts of PDL that would work as standalone parts, and the type-generic stuff is one. Probably a different direction from what your tool enables.

        One of the problems with the crazy nesting of macros (other than understanding how they fit together) is trying to trace through it in the debugger :-) So your example is exactly the sort of case where I think cpppp would help. Instead of a header file full of crazy macros, you'd have a cpppp template module which you could call from other code, and the output would be plain old readable C code that you then feed to the compiler and have an easy debugging session.