> > 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
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
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
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
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
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
6 matches
Mail list logo