🚀 go-pugleaf

In article <LUBKT.92Aug20094704@synergy.CC.Lehigh.EDU> lubkt@synergy.CC.Lehigh.EDU (Binod Taterway) writes:
>
>struct p_table {
>	char	*parameter_name;/* name of the parameter */
>	bool	specified; 	/* whether or not it is user-specified */
>	short	type; 		/* Integer, string, long, etc. */
>	char	*default_value; /* Default value */
>	char	*value; 	/* User-specified value */
>} P_TABLE;
>
>P_TABLE p_table[] = {
>	{"xyz_directory", TRUE, TYPE_STRING, "c:\xyz_orig", "c:\xyz"},
..
>}
>
>Though not implemented yet, I am not convinced if this the best
>approach. If you know of any other approaches to reading a
>configuration file, please throw in your two cents. Thanks.

I haven't done this for configuration files, but a very nice way to 
implement command line parameters that are of lots of different types and 
effects is to use a message-passing strategy.  In your case, this would mean 
something like this:

1.  Create a collection of objects or whatever that need to know about the
parameters.  I don't know how you'd implement this in C, but an array of 
structures like you had is probably as good a way as any.  In an OOP 
language, a polymorphic collection is ideal.  Give each of them some default 
behaviour, in case the parameter is never specified.

2.  Do minimal parsing of the config file line, probably just breaking it up 
into parameter name and parameter value (as a string).

3.  Pass a message containing each parsed line to every object in the 
collection.  If they care about that particular parameter, they'll act on 
the value; if they don't, they'll just ignore it.

The advantage of this approach is that you can have quite sophisticated 
parsing for particular parameters localized in the code that deals with 
those parameters, but you don't need to write one monster parser that 
handles every possible case when it reads the config file.

In case you're interested, the application where I did use this approach was 
the not-yet-released-but-maybe-sometime update of my disassembler DUMPPROG.
You can specify a range of addresses to disassemble in a quite general 
format, because the various kinds of objects it knows about can each 
recognize references to themselves.  The delays on release don't come from 
using this approach :-), but rather from indecision on how much to put in 
the update.

Duncan Murdoch
dmurdoch@mast.queensu.ca