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

Groups > comp.lang.c > #29956

Re: Favourite Pattern for Processing Zero, Once, Multiple

Show all headers | View raw

On 1/11/2013 14:15, Fred K wrote:
> On Friday, January 11, 2013 10:56:21 AM UTC-8, 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.
>
> Ouch! shades of strtok()
> This design is not re-entrant-safe, and definitely not threadsafe.
>

I meant for that to be in the 'state' parameter, shown above. :)

>
>>
>>
>>
>> '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 would consider something like this:
>
> bar(state_type state, char ic, char * oc, MyCallback foo);
>
> where bar internally calls foo the requisite number of times.
> Perhaps in this scenario the oc parameter is not even needed.
>

Right, that was one of the possibilities I'd mentioned upthread.  Just 
out of curiosity, does this call-back strategy score special points as 
opposed to other strategies (such as repeated calls to 'bar' until 
observing an "end-of-sequence" value), or is it roughly a matter of 
individual preference, for you?

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