C ++什么更糟糕的抽象或转换?

时间:2010-07-27 20:03:40

标签: c++ encoding cross-platform

我有疑问:

或者我抽象出我的字符串类型并隐式使用本地字符串类型或者我使用类似ICU的东西并在需要时转换为本地类型。

让我举个例子:

enum StringKind {
  ICU_STRING,
  STD_STRING,
  MSCORLIB_STRING,
  NSSTRING,
  ... /* You get the picture */
};

template<class E>
class _MyString {
};

template<>
class _MyString<ICU_STRING> {};

template<>
class _MyString<NSSTRING> {};

#if defined(__ICU_INSTALLED__)
typedef _MyString<ICU_STRING> MyString;
#elif defined(__DOT_NET__)
typedef _MyString<MSCORLIB_STRING> MyString;
/* ... */
#endif

或者我只是在我的代码中使用ICU实现并将UnicodeString转换为该运行时的characterencoding。 请注意,字符串可以在我的实现中变得非常大!

我该怎么做/选择?

谢谢,

菲利普

3 个答案:

答案 0 :(得分:2)

  

为什么字符串的大小是个问题?   您需要Unicode(或至少   超越ASCII的东西)和你   接受额外的记忆   要求,或者你使用的东西   像std :: string。快速浏览一下   尽管如此,ICU仍将与UTF-8合作   有一点额外的工作,那就是   处理时与ASCII相同   只有ASCII字符。 - 大卫   索恩利

字符串的大小是最大的问题。 想象一下,你有一个内存为100 MB的字符串。选择最后一个选项,并且所有字符串都保存在UnicodeString(icu)中...由于代码是跨平台的,因此其他一些代码需要以自己的格式显示内容,例如Mac上的NSString或dotNet平台上的System.String

现在你必须创建一个相同大小的临时缓冲区,甚至可能更大(UTF8每个字符最多需要6个字节),在其上运行转换器,然后使用内容创建所选类型的新字符串那个缓冲区。在这个过程的某个地方,你最终得到3个字符串,都是一样的。使用300多MB只是因为一行代码需要某种类型的东西......真是太棒了!

现在想象一下,这个转换代码被多次调用,并且可能在多个线程上调用。

我们不幸的是有64位来解决我们所有的记忆问题; - )

答案 1 :(得分:0)

我个人赞成typedef。我甚至都不确定原因。

100MB字符串。这解决了。使用typedef。

答案 2 :(得分:0)

看看ICU的UText接口。它们旨在允许非连续存储字符串。