在 C++ 中，为什么要使用 `uint8_t` 来声明字符串？

Question

作为使用 React Native 的移动开发人员，我需要使用创建和加密文件的 C++ 代码。我对 C++ 没有太多经验（我上次写一些东西已经是 15 年前在大学时的事了）。

如果我错了，请纠正我。

这让我很烦恼。这是文件的类型定义：

typedef struct File 
{
    uint8_t FileName[64];
    uint8_t userName[64];
}File;

为什么要使用类型uint8_t来存储字符串而不是std::string？

后来，事情变得更加扑朔迷离。我们需要将所有字符一一解析出来，并写入到临时文件中。

#define FILE_NAME_LEN   64


CustomFile CFile::getCustomFileFromFile(tFile f_File)
{
    CustomFile returnValue;
    for(int i = 0;i<FILE_NAME_LEN;i++){
        returnValue.FileName[i] = f_File.FileName[i]; 
    }
    for(int i = 0;i<FILE_NAME_LEN;i++){
        returnValue.user_name[i] = f_File.user_name[i];
    }
    return returnValue;
}



bool WriteEncryptFile(QString fpath,tFile *p_tFile)
{
    // Convert the tFile object to a CustomFile object
    CustomFile customFile = CFile::getCustomFileFromFile(*p_tFile);
}

Answer 1

\n

为什么要使用类型uint8_t来存储字符串而不是std::string

\n

\n

因为决定这样做的人都是 C 开发人员，对惯用的 C++ 缺乏专业知识。这也可以从以下习惯中看出：

\n

\n
• 使用uint8_t而不是std::uint8_t尽管存在潜在的兼容性问题，但
\n
• 使用原始数组而不是std::array\n
  \n
  • 与 C 风格数组相比，使用 std::array 有何优点？
  \n
  \n
\n
• 使用typedef struct File即使typedef此处不需要
  \n
  • 公平地说，如果这是在 C/C++ 兼容性标头中，那么最后的项目符号是完全合理的
  \n
  \n
\n
• 使用宏代替constexpr常量（假设这不是您的代码）\n
  \n
  • 什么时候我应该更喜欢 constexpr 变量而不是宏？
  \n
  \n
\n

\n

话虽这么说，也有实际原因。\nstd::string执行动态分配，这可能并不理想，尤其是在嵌入式环境中。\n不过，使用它可能更有意义char FileName[64];。

\n

使用uint8_t可能是出于使代码“更可移植”的愿望，因为char不能保证为 8 位大（它可以更宽）。它可能在您将编译代码的任何机器上，但仍然有些人对这种技术性和使用感到恼火uint8_t。另请参见uint8_t \xe2\x89\xa0 什么时候是无符号字符？

\n

它也可能是由 的不同符号引起的char，但signed char还是unsigned char解决了这个问题。另请参见char 默认情况下是有符号还是无符号？

\n

如果您可以自由修改原始代码，并且可以接受动态分配，则可以简单地编写：

\n

struct File {\n    std::string FileName;\n    std::string userName;\n};\n

\n

如果您需要所有字符串数据都在 中struct，则可以使用std::array<char, 64>。\n这仍然简化了后续代码，因为您可以编写：

\n

// std::array has an assignment operator\nreturnValue.FileName = f_File.FileName; \n

\n