【问题标题】:Wide String vs String , Does it affect performance in Windows C++Wide String vs String ,它是否会影响 Windows C++ 中的性能
【发布时间】:2013-06-04 19:33:57
【问题描述】:

我在我的 C++ 项目中处理大量 Unicode 文件路径。我在我的代码中执行检查,如果它们足够好以适合多字节字符串,我将其保留为普通字符串 (std::string) 变量,如果字符串不适合多字节,我将其用作宽字符字符串。

我的问题是我是否可以将路径完全用作 wstrings ..?它会影响性能吗,我必须使用 wstring 进行一些字符串操作、文件打开、创建、重命名和删除。因此,与其检查多字节或宽字符字符串,我想直接将其用作 wstring,这将为我节省很多 if/else。

bool IsUnicodeWString(const std::wstring &_WStr)
{
  WCHAR* posUnicodePath = (WCHAR*)_WStr.c_str();
  size_t multiByteLen = wcstombs(NULL, posUnicodePath, 0) + 1;
  int tempLength = 0;
  if (multiByteLen > 0)
  {
    TCHAR* _tmpTChar = new TCHAR[multiByteLen + 1];
    memset(_tmpTChar, '\0', multiByteLen + 1);
    tempLength = wcstombs(_tmpTChar, posUnicodePath, multiByteLen);
    if (tempLength == std::string::npos)
    {
      multiByteLen = 0;
    }
    delete[] _tmpTChar;
  }
  if(multiByteLen == 0 || multiByteLen == std::string::npos) { // Is Unicode file 
    return true;
  }
  else{
    return false;
  }
}

if(IsUnicodeWString) {
        // Use wstring [ Operations - String Manipulations,FilePath used for Open,Read,Write,Create,Delete,Rename,etc]
} else {
        //string  [ Operations - String Manipulations,FilePath used for Open,Read,Write,Create,Delete,Rename,etc]
}

请分享你的想法...

【问题讨论】:

  • 您应该让所有东西都无条件使用std::wstring 并完全忘记将MBCS 存储在std::string 中,或者切换到UTF-8 而不是MBCS,这样就不会有数据丢失的可能性(MBCS 不是无损),然后在调用需要 UTF-16 的 API 函数时在 UTF-8 和 UTF-16 之间进行转换。
  • 在担心速度之前先担心它是否正确。坚持使用一种格式会简化代码,并且更容易使其正确。
  • 我的观点是,你的检查和转换功能会比在任何地方都使用宽字符串要昂贵得多。
  • 几乎所有 Windows(完全使用字符串)在内部都使用宽字符串,因此在大多数情况下,使用宽字符串版本比使用窄字符串版本便宜。大多数窄字符串函数只是创建一个等效的宽字符串,然后调用宽字符串函数。
  • 以下划线后跟大写字母开头的标识符保留用于执行。不要使用它们,而是使用_wstr 或者只是去掉下划线。演员阵容也是不必要的。使用&_wstr[0]

标签: c++ performance widestring


【解决方案1】:

在 Windows 中,尽量使用wchar_t。因为它是 Windows 中的默认字符表示,内核也使用 wchar_t 作为默认值。所有 ANSI API 都是 UNICODE API 的封装。如果你反汇编 ANSI API,你就会知道真相。

此外,如果可能,请使用 ATL::CString 代替 std::(w)string。因为它使用的引用计数和类的大小等于指针大小(32 位中的 4 个字节和 64 位中的 8 个字节)。这意味着您可以直接从函数中返回 ATL::CString 而不会降低性能。

【讨论】:

    猜你喜欢
    • 2010-09-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-17
    • 2021-04-04
    • 2011-07-26
    • 1970-01-01
    相关资源
    最近更新 更多