字符串资源问题的新思路

前两天OTA WM客户端为了字符串资源的问题进行了激烈的交锋.
一派主张使用INI文件来定义字符串.
另一派主张使用VC的资源文件来定义字符串.
鉴于交锋很激烈,双方都很有道理.所以我在此就不点评了.直接抛砖引玉了.

在头文件中这样定义字符串数组:
const char* StrTab_Connecting[] = {
    "正在连接..."
    ,"Connecting..."
};
const char* StrTab_Disconnection[] = {
    "断开连接..."
    ,"Disconnection..."
};
const char* StrTab_Login[] = {
    "正在登录"
    ,"Disconnection..."
};
const char* StrTab_Logout[] = {
    "退出..."
    ,"Logout..."
};
.................................
这样使用字符串:
        StatusNotify(StrTab_Connecting[Config::GetLanguage()]);
  说明:其中  StatusNotify()  函数要求传入一个字符串做为参数
             Config::GetLanguage()从配置中读取语言设置  0:中文   1:英文

That's all.就这么简单.
现在来说说这个方法的优点:
1, 用头文件定义,更符合C++程序员使用习惯.如果交由专业人员进行多语言的翻译工作,那么可以让他们直接修改
这个头文件,由上可见,这个头文件的格式还是很简单的,翻译人员应该可以理解,并且适应. 另外,翻译完的还要再编译
一次,可以由编译器检查出不小心造成的格式错误
2, 效率高!!这一点就不多说了.
3, 使用字符串处的代码简洁,可以省去很多的 if  else    switch  case .....
以上,仅供参考.

另附上讨论意见:

这个方法确实不错，核心思路和ini文件的一样，就是把文字资源集中到一个非常规律
的文件中，使得翻译打包快速了很多, 不过似乎有一个致命缺陷,整个产品有多个工程
组成(exe,DLL),OTASecure有10个,为了使所有的进程和DLL 的文字都统一到这个文件
中，这个文件必须在基础的DLL中，其他工程依赖他，然后将其导出给其他所有工程用,
这些工程中的所有界面文件都包含他,这样没往里面添加一个字符数组，就会引发所有
的界面文件编译,每一次编译几十分钟。从而极大地增加了软件的开发周期。
可以考虑改进,将字符串的寻找选择封装在cpp中（给一个nRescurceID和nLanguageID）
在cpp中返回一个string。翻译时翻译这个cpp。

按你的使用方法是有可能会加长编译时间．但是应该也不至于到影响开发周期的程度．
另外，还有是办法避免你提到的问题的．
    你可以建一个单独的DLL工程,这个工程只包含这些字符串的定义,然后导出所有的字符
串.要使用字符串资源的工程直接依赖它.这样如果新增一个字符串的话,只要编译这个工程
就可以了,其他的工程可以完全不用重新编译.而且可以在软件发布以后方法地单独升级语言.