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

Groups > comp.lang.c > #29951

Re: Favourite Pattern for Processing Zero, Once, Multiple

Show all headers | View raw

On 1/11/2013 07:15, BartC wrote:
> "Shao Miller" <sha0.miller@gmail.com> wrote in message
> news:kco8gq$mao$1@dont-email.me...
>> On 1/10/2013 22:20, Ben Bacarisse wrote:
>
>>> Does this crop up for real?  I'd try to find a cleaner way to write the
>>> whole bar() + foo() interaction.
>
> That's the key I think (see below).
>
>> Sometimes 'bar' will have multiple characters to emit, and the caller
>> needs to call it multiple times to get all of the characters.  ("Here's
>> one translated character, but call me again because I have more.")
>>
>> Could be useful for escape sequences: "123${special}ABC" where the '$'
>> through until the 'l' wouldn't emit anything, but then the subsequent '}'
>> would cause some special sequence to be emitted, where 'bar' would know
>> what to emit, but would have to be queried repeatedly until it finished
>> emitting the special sequence.
>
> At first glance this seems perfectly straightforward: bar is just called
> repeatedly until the 'EOF' marker you mention is returned. In this case,
> bar() returns the next character in the sequence, rather than some code. If
> the "123" in your example was consumed with no output, then bar wouldn't
> return until there was something to return, in this case the first
> character
> of whatever replaces "${special}".
>
> But it gets more complicated when you have to consider where this input
> string comes from. There might be some global state containing the input
> stream, the current position in that stream, and the current position in
> any
> translation string. Or that state might be contained inside bar().
>
> Or perhaps the caller might supply bar() with the next input character (and
> bar() needs some look-ahead to operate properly). Or a pointer to a struct
> containing the state (so that bar() can be called from different places,
> all
> with their own strings to translate).
>
>> So I thought it was a bit of an interesting challenge and I wonder what
>> strategies folks might've or might come up with, as a general pattern.
>
> It's not clear what the roles of bar() and foo() are. Maybe one of those
> returns the next translated character, but some more information is
> needed. The whole thing seems a bit like a tokeniser, or at least has
> some of the same problems to be solved.
>

Yeah I was trying to abstract away the details and ask about a general 
pattern (since that's what I'm interested in), but maybe the code 
example was not illustrative enough. :)

For the subsequent translation scenario I tried to describe, the caller 
is responsible for getting a single input character 'ic'.  However they 
do it should be opaque to the translating function, 'bar'.  The caller 
calls 'bar' to translate 'ic' to '*oc'.

   extern return_type bar(state_type state, char ic, char * oc);

'bar' might not emit any output character '*oc' if it's not yet ready. 
In that case, the caller shouldn't work with '*oc'; shouldn't send it 
wherever output is going.

'bar' might emit '*oc' and have nothing more to emit until processing 
the next 'ic' or beyond.

'bar' might emit '*oc' and inform the caller that there are more output 
characters pending, so the caller should call 'bar' again until they've 
been consumed.  In this case, 'ic' is ignored for subsequent calls to 
'bar' as 'bar' already knows what sequence it wishes to emit based on 
the 'ic' that triggered it.

'foo' was really just a place-holder for "something the caller does with 
the results of 'bar'".  This might be to put the output characters in a 
buffer or to send them to a stream.

I'm interested in general C patterns for this kind of scenario without 
getting too distracted by this particular example of "translating 
characters".  Having said that, maybe working with this example scenario 
is a better idea.

-- 
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily,"  -- Richard Harter

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-10 17:53 -0500
  Re: Favourite Pattern for Processing Zero, Once, Multiple "BartC" <bc@freeuk.com> - 2013-01-10 23:26 +0000
    Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-10 18:49 -0500
      Re: Favourite Pattern for Processing Zero, Once, Multiple "BartC" <bc@freeuk.com> - 2013-01-11 00:23 +0000
  Re: Favourite Pattern for Processing Zero, Once, Multiple Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-11 03:20 +0000
    Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-11 00:38 -0500
      Re: Favourite Pattern for Processing Zero, Once, Multiple Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-01-11 12:10 +0000
        Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-11 13:37 -0500
      Re: Favourite Pattern for Processing Zero, Once, Multiple "BartC" <bc@freeuk.com> - 2013-01-11 12:15 +0000
        Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-11 13:56 -0500
          Re: Favourite Pattern for Processing Zero, Once, Multiple Fred K <fred.l.kleinschmidt@gmail.com> - 2013-01-11 11:15 -0800
            Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-11 14:28 -0500
          Re: Favourite Pattern for Processing Zero, Once, Multiple Greg Martin <greg@softsprocket.com> - 2013-01-11 11:22 -0800
            Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-11 15:23 -0500
              Re: Favourite Pattern for Processing Zero, Once, Multiple Greg Martin <greg@softsprocket.com> - 2013-01-11 13:09 -0800
          Re: Favourite Pattern for Processing Zero, Once, Multiple "BartC" <bc@freeuk.com> - 2013-01-11 22:09 +0000
          Re: Favourite Pattern for Processing Zero, Once, Multiple Paul N <gw7rib@aol.com> - 2013-01-12 04:49 -0800
            Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-13 20:30 -0500
  Re: Favourite Pattern for Processing Zero, Once, Multiple glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 21:02 +0000
  Re: Favourite Pattern for Processing Zero, Once, Multiple Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-13 20:28 +0200
    Re: Favourite Pattern for Processing Zero, Once, Multiple Shao Miller <sha0.miller@gmail.com> - 2013-01-13 16:12 -0500

csiph-web