[9fans] s_putc and Runes - Plan9

This is a discussion on [9fans] s_putc and Runes - Plan9 ; I’ve been appending single Runes to Strings, so I checked /n/sources/plan9/sys/src/libString/s_putc.c to see if it handled Runes. Is there a reason it doesn’t, or that s_putrune doesn’t exist? Here’s my implementation, using none of String internals: void s_putrune(String *s, Rune ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: [9fans] s_putc and Runes

  1. [9fans] s_putc and Runes

    I’ve been appending single Runes to Strings, so I checked
    /n/sources/plan9/sys/src/libString/s_putc.c to see if it handled
    Runes. Is there a reason it doesn’t, or that s_putrune doesn’t exist?

    Here’s my implementation, using none of String internals:

    void
    s_putrune(String *s, Rune r)
    {
    char rbuf[UTFmax];
    s_nappend(s, rbuf, runetochar(rbuf, &r));
    }

    or as part of the library (where I’m a bit shakier on the semantics):

    void
    s_putrune(String *s, Rune r)
    {
    char rbuf[UTFmax];
    int n;
    if(s->ref > 1)
    sysfatal("can't s_putc a shared string");
    if (s->ptr >= s->end - n=runelen(r))
    s_grow(s, n+1);
    (s->ptr) += runetochar(s->ptr, &r);
    }

    --Joel


  2. Re: [9fans] s_putc and Runes

    > void
    > s_putrune(String *s, Rune r)
    > {
    > char rbuf[UTFmax];
    > s_nappend(s, rbuf, runetochar(rbuf, &r));
    > }


    This is fine.

    > or as part of the library (where I'm a bit shakier on the semantics):
    >
    > void
    > s_putrune(String *s, Rune r)
    > {
    > char rbuf[UTFmax];
    > int n;
    > if(s->ref > 1)
    > sysfatal("can't s_putc a shared string");
    > if (s->ptr >= s->end - n=runelen(r))
    > s_grow(s, n+1);
    > (s->ptr) += runetochar(s->ptr, &r);
    > }


    Why bother with these details? The above is fine. If it ever
    became too slow, the right thing to do would be to fix s_nappend,
    not code around everything here. Further, this code is *very*
    unlikely to be the bottleneck -- you're calling it once per at most
    3 bytes, so the extra little bit you might or might not be saving
    this way pales in comparison to the added complexity.

    The main reason there is no Rune support in the String
    library is that it is not widely used. It was written for upas
    and later extracted, but the interface is a bit clunky.

    I confess that most of the time, when I need to write to a
    growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.
    It's just easier, and you get all the print verbs!

    Russ

  3. Re: [9fans] s_putc and Runes

    exactly. time spent optimizing something that uses 3% of the CPU
    by 10% is better spent going to the beach, or almost anything.

    On 2/5/07, Russ Cox wrote:
    > > void
    > > s_putrune(String *s, Rune r)
    > > {
    > > char rbuf[UTFmax];
    > > s_nappend(s, rbuf, runetochar(rbuf, &r));
    > > }

    >
    > This is fine.
    >
    > > or as part of the library (where I'm a bit shakier on the semantics):
    > >
    > > void
    > > s_putrune(String *s, Rune r)
    > > {
    > > char rbuf[UTFmax];
    > > int n;
    > > if(s->ref > 1)
    > > sysfatal("can't s_putc a shared string");
    > > if (s->ptr >= s->end - n=runelen(r))
    > > s_grow(s, n+1);
    > > (s->ptr) += runetochar(s->ptr, &r);
    > > }

    >
    > Why bother with these details? The above is fine. If it ever
    > became too slow, the right thing to do would be to fix s_nappend,
    > not code around everything here. Further, this code is *very*
    > unlikely to be the bottleneck -- you're calling it once per at most
    > 3 bytes, so the extra little bit you might or might not be saving
    > this way pales in comparison to the added complexity.
    >
    > The main reason there is no Rune support in the String
    > library is that it is not widely used. It was written for upas
    > and later extracted, but the interface is a bit clunky.
    >
    > I confess that most of the time, when I need to write to a
    > growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.
    > It's just easier, and you get all the print verbs!
    >
    > Russ
    >


  4. Re: [9fans] s_putc and Runes

    i think this is a very powerful idea. although the
    interface is high-level, and if you need to format a
    structure, you need to write a print format, it results
    in a good old char*, not a String*. the code that uses
    String*s tends to have a fair percentage of code converting
    between char* and String*. in a few cases i've removed
    30 or 40 lines of code by converting from a String* to a
    char*/*print because the conversion goo and String helper
    functions and conversion goo were no longer needed.

    - erik

    On Sun Feb 4 22:25:53 EST 2007, rsc@swtch.com wrote:
    > I confess that most of the time, when I need to write to a
    > growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.
    > It's just easier, and you get all the print verbs!
    >
    > Russ


  5. Re: [9fans] s_putc and Runes

    > I confess that most of the time, when I need to write to a growable
    > string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush. It's
    > just easier, and you get all the print verbs!


    A unification of String and Fmt would be an interesting project, if I
    had the time. Maybe if someone needs/wants to implement a language
    with a built-in string type…

    --Joel


  6. Re: [9fans] s_putc and Runes

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    On 5-Feb-07, at 11:52 AM, Joel Salomon wrote:
    > Maybe if someone needs/wants to implement a language
    > with a built-in string type$B!D(B


    That's crazy-talk.

    ;-)

    Paul

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (Darwin)

    iD8DBQFFx6SrpJeHo/Fbu1wRAhGnAKCPibBrE9WPP38TT7aV9cbFyoxOKACfe68A
    DfPmHYkqeDPGx5Z0HukrtGg=
    =s/8V
    -----END PGP SIGNATURE-----

  7. Re: [9fans] s_putc and Runes

    > > Maybe if someone needs/wants to implement a language
    > > with a built-in string type…

    >
    > That's crazy-talk.


    “Then let’s talk crazy.” — Simon Tam

    I’m taking a compilers course now. All sorts of terrible ideas are
    floating past my mind. ☺

    --Joel


  8. Re: [9fans] s_putc and Runes

    well all of this was "solved" ten years ago, because limbo
    has a well performing string type. it's so convenient.

    brucee

    On 2/6/07, Joel Salomon wrote:
    > > > Maybe if someone needs/wants to implement a language
    > > > with a built-in string type…

    > >
    > > That's crazy-talk.

    >
    > "Then let's talk crazy." — Simon Tam
    >
    > I'm taking a compilers course now. All sorts of terrible ideas are
    > floating past my mind. ☺
    >
    > --Joel
    >
    >


+ Reply to Thread