Text Filter Support Routines
 
The astute reader will notice that I glossed over two points in the description of Text Filter Programs.
 
  1. While the parsing of each option argument on the command line is the same in all filters, the actual meaning of the arguments differ. In the first implementation of this filter package the main routine had to process the option arguments, remove them from the command line, and then pass the remaining non-option arguments on to the filter routine.
  2. Also, there is no provision for handling output files. The user routine thinks it is writing to standard output (stdout) and it actually is. It assumes the user will redirect stdout to wherever she or he wants it to go. There can be only one output file. Even if several input files are specified they output will be written to only one file.
 
 
As I said above, in the original design the user routine had to process all the option arguments and remove them from the argc and argv passed to filter() I've since written a support routine, ParseOptions() that will take part of this burden away from the user. The user no longer has to loop through the command line parsing each argument. As with filter(), the user passes argc, argv, and an additional function pointer to ParseOptions(). ParseOptions() removes each option from the command line and passes it to the user-supplied routine for interpretation. ParseOptions() also modifies argc and argv so that when it returns the option arguments have been removed from the command line. ParseOptions performs similarly to the *nix routine getopt, but it compiles on non-*nix platforms and acts in a way that is more helpful to the filter() routine. Please see the description of ParseOptions to see what it does.

I've since written other support routines in addition to filter() and ParseOptions().

Previous  |  Next ]     [ Up  |  First  |  Last ]     (Article 25 of 485)
 
Comments, flames, broken links?
Please send email to maintainer@intricate-simplicity.com