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

Groups > comp.lang.c > #29960

Re: Favourite Pattern for Processing Zero, Once, Multiple

Show all headers | View raw

On 1/11/2013 14:22, Greg Martin wrote:
> 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.

Sorry about that.

> 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.
>

Right, callbacks were one of the possibilities mentioned upthread.  It 
does seem a bit like an asynchronous problem...  Maybe even possible to 
think of in terms of co-routines.  (But not in C.)

Do call-backs have a major advantage over some other strategy, such as 
repeated calls to the "emitter" and having the "observer" continue until 
observing an "end-of-sequence" value?  Or is it more a matter of 
individual preference, would you say?

Thanks for the feed-back!

-- 
- 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