[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Character encoding design
From: |
Benjamin Wolsey |
Subject: |
Re: [Gnash-dev] Character encoding design |
Date: |
Sun, 19 Oct 2008 13:18:43 +0200 |
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 write a
> string class that can internally use std::string, std::wstring
> or a third party library representation?
Yes, exactly this is what I've been experimenting with. I had one
implementation that inherited from std::string with a few extras (it is
enough to support SWF5, but won't do unicode) and another that used
libICU's UnicodeString internally, but mainly mimicked the std::string
interface. They could both be used interchangeably, though obviously the
the std::string implementation fails tests.
I agree it wouldn't be useful to reimplement a whole string class. Both
std::string and UnicodeString handle copy-on-write and other performance
issues themselves, so a wrapper round these classes would be enough.
bwy
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil