NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/msdos/programm/8663

Text File | 1992-08-20 | 2.8 KB | 65 lines

Newsgroups: comp.os.msdos.programmer
Path: sparky!uunet!utcsri!torn!news.ccs.queensu.ca!mast.queensu.ca!dmurdoch
From: [e-mail] (Duncan Murdoch)
Subject: Re: Table lookup ...
Message-ID: <[e-mail]>
Lines: 52
Sender: [e-mail] (Netnews control)
Organization: Queen's University
References: <[e-mail]>
Distribution: comp.os.msdos.programmer
Date: Thu, 20 Aug 1992 15:16:31 GMT

In article <[e-mail]> [e-mail] (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
[e-mail]