|Code Generators email@example.com (Kenn Heinrich) (1991-04-12)|
|Code Generators firstname.lastname@example.org (Mike Lichak) (1998-08-22)|
|Re: Code Generators email@example.com (Chris F Clark) (1998-08-24)|
|Re: Code Generators firstname.lastname@example.org (1998-08-24)|
|Re: Code Generators email@example.com (Joachim Durchholz) (1998-08-25)|
|Re: Code Generators firstname.lastname@example.org (1998-08-25)|
|Re: Code Generators email@example.com (1998-08-25)|
|From:||Joachim Durchholz <firstname.lastname@example.org>|
|Date:||25 Aug 1998 13:19:05 -0400|
You've just described the classical problems of code generators. Ways
1) Make a library. The template code goes into library functions which
are called as needed by your report. This will usually make the report
somewhat longish, and it's *much* work setting up and debugging such a
2) Make an OO library (and maybe switch to an OO language). The template
code goes into base classes, and subclasses override specific behaviour
as needed. The report constructs a Report object and then does whatever
it wants to do with it (usually user input and printing).
3) Use or build a macro processor for a code generator. Among the macro
parameters, have some that are just copied into the generated source at
the appropriate place. Make these parameters optional so you don't have
to write them down if they aren't needed (and use an Ada-style facility
to specify just the 15th of 37 parameters). This has the advantage that
it is a quick fix, but be prepared for heavy rewrites of the inserted
code snippets whenever the code templates change (well, you'd have that
problem with any code generator).
Personally, I'd recommend one of the library approaches if you're
required to maintain your code over any length of time. Code generation
plus pasting in customer-specific code means you have zero decoupling
between standard and customer-specific code, which means if any of them
changes the other has to change as well.
Return to the
Search the comp.compilers archives again.