> No, I'd think that you should make a text rope for UTF-8 But that's what I made. UTF-8 is encoded as bytes. I can store the bytes in the rope just fine. The

> No, I'd think that you should make a text rope for UTF-8 But that's what I made. UTF-8 is encoded as bytes. I can store the bytes in the rope just fine. The rope has a very simple API, basically read() and write() functions, just like a standard FILE I/O API. Do you want to pick on file system developers that they should add APIs for write_UTF8(), write_LATIN1(), write_KOI8(), write_BYTES(), etc.? And then go to network API designers to do the same for the socket I/O functions? And so on? Of course you don't do that, that would be very bad factoring. And it's just the same for a rope API. > The more assumptions about your data you've made at the compile time, the less runtime conditioning you'd need, the faster your code would be. This is true in general, but the rope is just a storage. No processing happens there. The rope couldn't care less what things you store there. There is no point of having multiple identical read/write implementations. But if you insist, I recommend to ask for an UTF-8 optimized HDD at your local computer shop :-) > making your program able to deal with different internal encodings is a PITA If your program has to deal with multiple external encodings, either you can convert at the boundaries to a canonical internal encoding, or you can't in which case it probably becomes a little more work since you have to convert at different places. This has nothing to do with what I said, though.