On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> Have you guys seen Topaz?
I may have heard of it, yes.
> The other major suggestion I have is to avoid "void *"
> interfaces.
I'm using void * to avoid char *. :)
> Do we really need a string_make() that takes
> the encoding enum?
Yes.
> Aren't encodings different enough that
> we'd want string_make_ascii(), string_make_utf32(), ...
No. Look at the code for string_make. If you're already
passing *in* a UTF32 buffer, why do we need any special
processing for UTF32?
> Maybe I've been doing C++ too long,
Any C++ is too much C++.
> but taking advantage of compiler type checks as much as possible
> seems like an excellent goal -- especially since the various
> string_* functions are going to be visible in user code.
And that'll remove the abstraction I've fought so hard to
put in.
> The use of an encoding enum seems a little weird, but once
> you explain why it will probably make sense. Right now the
> only thing it seems good for is the transcoding system --
> everything else is slower and vtables are more cumbersome
> because you have to manage a vtable[num_encodings] array.
I don't know why I did this. Patches welcome.
> I'd make a string's encoding a direct pointer to its'
> vtable struct. The transcoding algorithm seems like it
> could be implemented using a string iterator on the source
> with a character-by-character append to the destination.
No, that's a really bad way to do it. We can special-case
things like UTF16 to UTF32.
> The destination can be pre-extended to the length of the source to
> avoid fragmenting memory.
Yes, I've thought about that, and that's what max_bytes is
for.
> How many encoding specific
> optimizations are there? Is it worth having a table of
> custom transcoders instead of using a generic algorithm?
Yes.
Simon
