登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

将CEGUI:: String全部换掉  

2009-02-20 22:53:16|  分类: Game |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

        这两天在看CEGUI,其中有个String类是32字节栈加速字符串实现,很多引擎里也都是这么实现的,应该算比较统一了。起初我对这份实现还是很敬重的,并没有要换掉的意思。后来再细看的时候发现问题还是比较大的。

        该类的功能并没有比std的string实现有明显的扩充,甚至还想做到与std::string的兼容,当然这个并不算缺点。
String本身是兼容UTF32(当然作者的实现是非标准的UTF32)和UTF8的,其中UTF8是在UTF32格式存贮的String中再建了一个临时缓冲区。如果加一个脏标记就可以避免每次build_utf8_buff的麻烦了。通过建立冗余的缓冲区来保持和标准string::c_str()的兼容显得稍微有点不值。

        String内部每个codepoint是用一个utf32(unsigned int)存的,其实两个字节已经足够了,win系统内部就是采用两个字节的,虽然这无法显示地球上所有的语言。有点浪费。

        最致命的一点是代码中将ASCII的char*和UTF8编码的utf8*(unsigned char*)混用,甚至我无法正确的通过cout打印出String的值,要保证代码中没有ASCII和UTF8编码的混淆是很难的,我对此持有怀疑。

        再三考虑后,决定换掉CEGUI:: String。自定义字符串无疑会加重和系统其他部分交互时的代价,再者性能也不一定会比std的string好到哪去。采用ASCII的std::string是没有任何问题的,而且在做字体文件的编码映射时会比较集中,但要在游戏中显示火星文貌似有点难度。

        最终,采用std::wstring,内部是以wchar_t存贮的Unicode 16bit格式,和Windows一致。值得庆幸的是Win系统对很多API都提供了普通字符和宽字符两个版本,但并非所有,所以在使用的时候还是需要适当的转一下的。

        结论:CEGUI自带的String不好用,换成std:wstring标准字符串是个不错的选择。


2011-3-28

    用了两年多的CEGUI,觉得将CEGUI自带的String换成std::wstring确实是非常明智的选择。避免编码混淆,避免乱码,方便外部使用交互。暂不理解作者为什么要采用DIY String?


2013-3-11
    为std::wstring找了篇文章支撑: 循序渐进全球化:支持 Unicode (MSDN),最佳实践:
  • 选择 UTF-16 作为您应用程序中文本的基本表示。UTF-8 应仅用于应用程序互操作性。避免逐字节处理并尽可能地使用现有 WCHAR 系统接口和资源。某些语言中字符之间的交互需要有关这些语言的专业知识。Microsoft 已使用由 Unicode 表示的大多数语言开发和测试了系统接口 – 除非您是多语言专家,否则重现此支持将非常困难。
  • 不要为了避免处理代理项而只选择 UTF-32。那样,数据大小将加倍,而且处理优势难以实现。如果您遵循先前在代理项处理方面的建议,则 UTF-16 应足以满足要求
  评论这张
 
阅读(2028)| 评论(6)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018