【问题标题】:C++ win32 loading strings from resourceC ++ win32从资源加载字符串
【发布时间】:2011-08-29 19:53:32
【问题描述】:

好的,所以我最近决定将我应用程序中的每个字符串都放入一个 STRINGTABLE 中,这样我就可以轻松地翻译成不同的语言。 我知道如何使用 LoadString() api,但这涉及到我为要加载的每个字符串都有一个不同的变量,如果我的应用程序有 100 个字符串,那就是很多变量。这是最好的方法吗?或者我应该创建一个全局变量,用作缓冲区以根据需要加载字符串?另外,由于无法知道我的字符串有多大,我应该创建一个足够大的缓冲区来保存我可能拥有的任何字符串,还是有更好的方法来做到这一点?

根据需要加载字符串也会对性能不利吗?有什么办法可以预加载吗?

RE:好的,我已经尝试创建一个大小为 256 字节的缓冲区并根据需要将字符串加载到其中,尽管我遇到了一个小问题......

这是我显示错误消息的代码,错误是“分配内存错误!”

LoadString(g_hInst, IDS_ERROR_MEMORY, szBuffer, sizeof(szBuffer)/sizeof(TCHAR));
MessageBox(NULL, szBuffer, TEXT("错误"), MB_OK | MB_ICONERROR);
ExitProcess(1);

我将缓冲区作为全局变量:TCHAR szBuffer[256];

这可行,但是,我想将“错误”文本也存储到字符串表中,并在我想显示错误时加载它,问题是这需要我有 2 个全局变量来加载字符串,并且有些地方我需要一次加载更多。

有比拥有多个全局变量更好的解决方案吗?

【问题讨论】:

  • 使用支持本地化的GUI框架会容易得多

标签: c string winapi api resources


【解决方案1】:

如果需要,您当然可以预加载它们。您只需要创建一个字符串指针数组并将每个字符串加载到该数组中。或者您可以使用哈希映射或类似的东西。

对性能不利?这取决于。如果您在用户界面中将这些字符串显示为提示,我看不出根据需要加载每个字符串将如何成为性能问题。无论如何,操作系统都会进行一些智能缓存,因此您不会为需要显示的每个字符串都敲击磁盘。另一方面,如果您要在紧密循环中处理这些字符串,那么最好将它们预加载到内存中,这样您就不必一直调用LoadString

就缓冲区而言,我总是分配一个缓冲区,该缓冲区与我期望在资源文件中拥有的最大字符串一样大。考虑到用户界面字符串通常非常小,一个 256 字节的缓冲区就绰绰有余了。比这更大的东西,我要么在启动时预加载到内存中,这样我就可以保留它,或者我编写了一个单独的方法,在加载时分配一个字符串,而不是保留一个缓冲区。

附加信息:

与其为字符串定义全局变量,不如考虑编写一个函数来加载资源字符串、制作它的副本并返回该副本。那就是:

char * LoadStringFromResource(uint id)
{
    // szBuffer is a globally pre-defined buffer of some maximum length
    LoadString(ghInst, id, szBuffer, bufferSize);
    // yes, I know that strdup has problems. But you get the idea.
    return strdup(szBuffer);
}

你的代码,然后变成:

char* errMem = LoadStringFromResource(IDS_ERROR_MEMORY);
char* errText = LoadStringFromResource(IDS_ERROR_TEXT);
MessageBox(NULL, errMem, errText, MB_OK | MB_ICONERROR);
free(errMem);
free(errText);

以上是 C 代码,但您可以轻松转换为 C++。特别是,您可能想要修改包装函数,以便它返回一个 C++ 字符串——当它超出范围时(使用智能指针或任何现代等价物)将自动释放该字符串。

【讨论】:

  • strdup() 不是 ISO C 标准的一部分,它更像是 Posix。 MinGW 接受它以 GNU C 方言编译。
  • 哇。因为我在一个例子中使用了strdup而被否决?残酷的。我什至评论了我的用法,以防止被指责。那好吧。没有取悦所有人。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-03-16
  • 1970-01-01
  • 2017-07-08
  • 2017-08-06
相关资源
最近更新 更多