Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #76598

Re: Data IO for project

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>

Show all headers | View raw


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


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