in reply to Re^3: Introducing the C Perl-Powered Pre-Processor
in thread Introducing the C Perl-Powered Pre-Processor

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.
  • Comment on Re^4: Introducing the C Perl-Powered Pre-Processor

Replies are listed 'Best First'.
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.