Re^2: Introducing the C Perl-Powered Pre-Processor

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.

Comment on Re^2: Introducing the C Perl-Powered Pre-Processor

Replies are listed 'Best First'.
Re^3: Introducing the C Perl-Powered Pre-Processor by etj (Priest) on May 13, 2024 at 20:51 UTC
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.	[reply]
Re^4: Introducing the C Perl-Powered Pre-Processor by NERDVANA (Priest) on May 13, 2024 at 22:16 UTC
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.	[reply]
Re^5: Introducing the C Perl-Powered Pre-Processor by etj (Priest) on May 14, 2024 at 12:39 UTC
That's a problem I'm aware of, having occasionally needed to use a non-printf style of debugging (though mainly to get a stack trace, it's still relevant). If the C compiler were to annotate the source-line information better for debugging symbols, this sort of thing would not be a problem. I have contemplated fixing this in the two major FOSS C compilers (gcc and clang), since that would then let me shorten PDL-generated C code even more by having a macro for the repeated "Code" part, but I have not yet done so.	[reply]