IRC channel logs
2023-07-22.log
back to list of logs
<rlb>...so when implementing something like string-map! with utf-8, I'm wondering if an internal happy-ish path might be to just generate the new segment as scm_wchar_t (utf-32) on the stack, with spillover to the heap, and then convert that to the new immutable stringbuf at the end. That guarantees at most two (re)allocations. <rlb>An alternative would be to build the utf-8 on the stack, with spill over to writing in-place in the new stringbuffer, but since we can't know the final length in advance, we'd either have to (likely) overallocate, or reallocate multiple times (since we'll have 1-4 bytes per new char). <rlb>Hmm, and that's almost certainly more complex, code-wise. OK, maybe I just answered my own question... <rlb>ACTION is finished with the initial internal/internal utf-8 bits and is working on the "external" internal code, i.e. srfi-13.c, etc. to reduce fine-grain string_set/ref use as much as possible. The sparse indexes work fine now too.