On Friday 15 July 2005 23:14, Andrew de Quincey wrote:
> > > [... that backend parser draft...]
> > > I get you - sounds cool... what about a structure containing a set of
> > > callback function pointers though? I think it might make the parser
> > > easier than doing it line by line.
> >
> > I generally don't like callbacks, as i don't like libraries which make
> > any assumptions about the program flow.
> >
> > But generally, it would be the same thing, just a different layout.
> >
> > The advantage is that you don't need any context pointers (a "void *"
> > probably does the thing, anyway), you don't need to declare (essentially
> > wrapper) functions for the stuff, and you know on the first view that
> > the program flow doesn't leave this loop.
> >
> > And you can feed in the data from whatever source. Though this stuff is
> > probably always read from a file, i generally like to let the
> > application do the "OS depending" stuff, especially because it's
> > relatively easy here (never more than one "result" per line).
> >
> > It's really only a design decision - i don't like callbacks, but that's
> > just my opinion.
> >
> > oh, another thing: If you don't use callbacks, you can easily write
> > wrappers for other languages. Using callbacks, this really really gets
> > difficult. for example with "swig" you can generate the wrapper code
> > automatically, and with my draft, you don't need any specials things, it
> > would just work.
>
> You're right - this way is much better. Prepare to see it implemented! :)
OK, I've been thinking about this. It makes it quite hard to do nicely for the
section oriented file formats. e.g. for multiplexes.conf:
[m]
key1=
key2=
key3=
[s]
key1=
key2=
When you're parsing the [m], you only know it ends when you hit the [s]
entry... this doesn't really fit nicely if you're passing it line by line,
and its not really feasible to go back to a line-oriented format for these
more complex files. So need to keep more complex state between lines for
these... something like:
struct multiplex_parser {
int state;
struct dvbcfg_multiplex* multiplex;
struct dvbcfg_service* service;
};
int dvbcfg_multiplex_parse_line(char* line, struct multiplex_parser* state);
The return code will indicate what was just parsed. Its up to you to
supply/update/free suitable multiplex and source pointers - they could be
malloced(), they could be pointers to a local temporary variables..
Unfortunately, parsing the entries will have to allocate temporary space -
e.g. for storing a list of dvbcfg_pid entries. Is this ok?
I'll be adding a call to zap the contents of a multiplex structure so you
could either just let the parsing accumulate values in the multiplex
structure OR you could copy them out to some other place, and zap the
structure contents each time something is parsed.
What do you think?
