Re: [Gnash-dev] Character encoding design

2008-10-19 Thread Benjamin Wolsey
> > The other difficulty is finding a way of enforcing the interface. > > Worry less about that. Python has no interface enforcement other than > the convention that variable names which begin with _ are private > names. > This is about the minimum header required to use UnicodeString instead

Re: [Gnash-dev] Character encoding design

2008-10-19 Thread Benjamin Wolsey
Am Samstag, den 18.10.2008, 09:26 -0700 schrieb Bastiaan Jacques: > I'm hesitant to go with reimplementing std::[w]string for our needs (since > we spent a lot of time removing our dependency on a self-developed > string class, previously). > > That said, would it be possible for our needs to writ

Re: [Gnash-dev] Character encoding design

2008-10-18 Thread Dossy Shiobara
Bastiaan Jacques wrote: > I'm hesitant to go with reimplementing std::[w]string for our needs (since > we spent a lot of time removing our dependency on a self-developed > string class, previously). Call me ignorant, but shouldn't Boost, with all its "greatness," have a decent Unicode-aware string

Re: [Gnash-dev] Character encoding design

2008-10-18 Thread Bastiaan Jacques
I'm hesitant to go with reimplementing std::[w]string for our needs (since we spent a lot of time removing our dependency on a self-developed string class, previously). That said, would it be possible for our needs to write a string class that can internally use std::string, std::wstring or a thi

Re: [Gnash-dev] Character encoding design

2008-10-18 Thread Russ Nelson
Benjamin Wolsey writes: > I favour using a custom string class in libcore only, because it can > solve all the problems most efficiently. The disadvantage is that it > requires changes to the core (mostly minor changes, but lots of > them). This is not a big disadvantage in my mind. The chang

[Gnash-dev] Character encoding design

2008-10-18 Thread Benjamin Wolsey
The present implementation of utf8 character handling is not very good. Strings are kept as utf8 std::strings, and (often completely) converted to std::wstring for every string operation, then sometimes back again for operations that changed the string. The second problem is that the standard libr