Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Templating system for generating C code?

by toma (Vicar)
on Mar 23, 2004 at 04:45 UTC ( #338891=perlquestion: print w/ replies, xml ) Need Help??
toma has asked for the wisdom of the Perl Monks concerning the following question:

I am writing a perl program that generates C code. My implementation so far looks like a rather mundane templating system. Is there a module designed for generating C? Or is there a general-purpose templating system which is good at generating C code? If not, I'll end up inventing yet another templating system.

My application generates C-language real-time signal processing code from a directed graph. The graph is specified in perl, as a bunch of function calls. These functions generate the C code.

Related ideas and concepts are also welcome.

It should work perfectly the first time! - toma

Comment on Templating system for generating C code?
Re: Templating system for generating C code?
by DamnDirtyApe (Curate) on Mar 23, 2004 at 04:54 UTC

    Have you looked at Template Toolkit? It's language-neutral, and I'm sure you could adapt it to generate the boilerplate C code, if that's what you're trying to do.

    NOTE: By language-neutral, I mean it's not just for generating HTML, or XML, or LaTeX, or whatnot. You can use it to generate whatever type of code you like.


    _______________
    DamnDirtyApe
    Those who know that they are profound strive for clarity. Those who
    would like to seem profound to the crowd strive for obscurity.
                --Friedrich Nietzsche
      The Template Toolkit looks like it would allow me to write chunks of C code to include bits of perl which would customize the code.

      So far I have been generating the C code with many small perl here documents, and interpolating perl variables as needed.

      It looks like Template Toolkit can do his with ease. But most of the toolkit documentation seems to be about embedding logic into the template.

      I think I would like to keep the logic outside of the templates, in the perl code. Am I missing something, is this a design trap?

      If I use the Template Toolkit in such a simplistic manner, is there still and advantage over a bunch of here documents?

      Somehow I feel like a novice again as I write perl that writes C. I have used HTML::Template for web work and written a ton of C code for signal processing, but now I am starting over again.

      It should work perfectly the first time! - toma
        If you want to keep the logic outside the template, then use HTML::Template. While it was originaly designed for generating HTML (as the name implies) there is nothing in it's makeup or functionality that is specificaly tied to HTML. I've used it to generate general text documents, and I can't see any reason why it couldn't be used to generate C code.

        What matija says about HTML::Template is true, in fact, any templating system will most likely fit the bill, personally, I like Petal, but that one has some Unicode bugs and XML quoting bugs, and requires your templates to be wellformed XML, which is most likely not what you want.

        At the moment, I only see two special needs for templating, string interpolation and recursive macros.

        For (intelligent) string interpolation, you will want to pass in any Perl scalar and have it automagically quoted correctly as a C string, in the same way that HTML::Template can automatically URL-encode or HTML-encode any scalar variable.

        While the C macro preprocessor can also take some of the work, it might be useful for you to have recursive macro calls in your templating system, especially if you want to construct complex macros from smaller parts or move all OS logic out into separate templates instead of cluttering your output with huge nested blocks of #IFDEF.

        I would start out with HTML::Template, code in the C-string-quoting function, and write the first generation templates in that. Then you will find out what additional functionality you need, and can move to the second incarnation.

        Here documents work well if all you have to do is replacing some variables. If you need more, especially conditions and loops, then the handling with here documents becomes ugly --- you may embed simpler conditions as @{[ $condition ? $foo : $bar ]}, but often you have to split the here doc into multiple parts.

        Regarding keeping the logic outside: most, if not all templating systems work by receiving their data from the outside and doing only the output work. Some templating systems additionaly have more features (up to a [% PERL %] directive to embed perl code), but it's up to you to use them or not.

        The biggest advantage of using a template module over the HEREDOCS is the ease with which you can substitute the templates to generate differnt output for whatever reason you might need to:

        • Change the code fragments that are generated to test optimised C code
        • Switch the language that is generated (Or add another!)
        • Use the same information to build documentation/diagrams

        The biggest advantage of encapsulating the "display" logic in the templates is that it simplifies the responsibilities of your application to:

        1. acquire input
        2. build the graph
        3. select a template
        4. pass the graph to the template
        5. write the output to disk
        and insulates your application from bugs introduced by changing the display logic.

        It also becomes much easier to produce all of those other formats that we might want because the templates now recieve all of the data in context and allow it to make output decicions based on the data rather than be an external holder to interpolated strings.

        This would allow you to generate your C project many different ways without having to edit and re-edit versions of your application.

        This allows you to maintain a parallel set of templates rather than "parallel" copies of the same application if you needed to test optimisation changes to your C code. Especially if changes to the output required changes to the display logic

        generator.pl --template=c generator.pl --template=c-optimise-poll vs generator.pl generator_test_c-optimise-poll.pl

        In the end what technique you decide to use depends on what you really want to do with the information you have.

        If you don't need all the stuff, don't bother with it, but I like it when I can write a few templates and the beginnings of a documentation outline cheap.

        It makes my manager happy to have documentation, and when my managed is happy I'm usually in a better mood :)

        --
        Clayton

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://338891]
Approved by Old_Gray_Bear
Front-paged by broquaint
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2014-07-22 11:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (110 votes), past polls