Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Data IO for project |
| Date | 2015-11-20 05:08 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <pan.2015.11.20.05.08.07.92000@nowhere.invalid> (permalink) |
| References | <n2kob0$68v$1@speranza.aioe.org> <pan.2015.11.19.19.59.07.387000@nowhere.invalid> <n2lpas$tl8$1@speranza.aioe.org> |
On Fri, 20 Nov 2015 01:26:18 +0100, Morten W. Petersen wrote: > The design today is a loop that "pulls" characters from a buffer, Until ... what? With a push parser, the feed() method retrieves characters until there aren't any more, at which point it returns. Then the next time you call feed() it continues from where it left off. It doesn't matter if the characters comprising a token (e.g. a tag, tag name, attribute name, etc) are split across multiple feed() calls. This is trivial with a pushdown automaton (bottom-up) design, where you have a single outer loop which consumes one character on each iteration, but it's the wrong way around for a top-down (e.g. recursive-descent) parser which expects to be able to read ahead until some particular point in the structure (e.g. the end of a tag or the end of an element). Providing a "push" interface to a top-down parser typically requires either 1. using threads/fibers/coroutines/etc, so the feed() function just appends characters to the back of the input queue while the parser itself reads from the front in a separate thread, or 2. having each feed() call run the parser until either a) it has enough data to return an "item" (e.g. tag or element), in which case it removes the corresponding data from the input (leaving any following data) and returns the item, or b) it reaches the end of the input without having seen a complete item, in which case it leaves all of the data in the input stream and returns nothing; on the next feed() it tries again with the now-enlarged input. Option 2 is inefficient, as you can end up having to repeat the parsing until it completes. Option 1 avoids that but requires some means to suspend execution whenever you run out of data and resume it later.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Data IO for project "Morten W. Petersen" <morphex@gmail.com> - 2015-11-19 16:03 +0100
Re: Data IO for project Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-19 08:12 -0800
Re: Data IO for project "Morten W. Petersen" <morphex@gmail.com> - 2015-11-19 18:42 +0100
Re: Data IO for project Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-19 12:15 -0800
Re: Data IO for project Robert Wessel <robertwessel2@yahoo.com> - 2015-11-19 16:17 -0600
Re: Data IO for project "Morten W. Petersen" <morphex@gmail.com> - 2015-11-20 01:16 +0100
Re: Data IO for project Robert Wessel <robertwessel2@yahoo.com> - 2015-11-20 00:15 -0600
Re: Data IO for project "Morten W. Petersen" <morphex@gmail.com> - 2015-11-21 00:37 +0100
Re: Data IO for project Nobody <nobody@nowhere.invalid> - 2015-11-19 19:59 +0000
Re: Data IO for project "Morten W. Petersen" <morphex@gmail.com> - 2015-11-20 01:26 +0100
Re: Data IO for project Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-19 16:46 -0800
Re: Data IO for project Nobody <nobody@nowhere.invalid> - 2015-11-20 05:08 +0000
Re: Data IO for project Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 02:21 -0800
Re: Data IO for project Ian Collins <ian-news@hotmail.com> - 2015-11-20 12:00 +1300
Re: Data IO for project "Morten W. Petersen" <morphex@gmail.com> - 2015-11-20 01:19 +0100
Re: Data IO for project asetofsymbols@gmail.com - 2015-11-21 12:29 -0800
Re: Data IO for project Ian Collins <ian-news@hotmail.com> - 2015-11-22 12:13 +1300
csiph-web