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

Groups > comp.lang.c > #29954

Re: Favourite Pattern for Processing Zero, Once, Multiple

Show all headers | View raw

On 13-01-11 10:56 AM, Shao Miller wrote:
> 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.
>

I found it a little difficult to grasp the initial scenario because of 
the magical occurrences going on in the functions. I think that to 
discuss patterns in any language the example needs to be have enough 
detail to represent the problem space. When I looked at your first post 
I thought you working on some strange sort of iterator but now it looks 
more like a emitter/observer type problem. The former I'd solve in C 
with an object passed as a parameter that maintains state information 
whereas the latter registering callbacks for each of the states might be 
easier to work with.

It sounds like an asynchronous problem and callbacks tend to work well 
for them. You don't actually inform the caller though state variables 
but through calling the functions they've provided.

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