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 <[EMAIL PROTECTED]> 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
