对我的应用程序进行的分析表明，它在字符串分配上花费了近5％的CPU时间。在很多地方，我都是通过64MB char缓冲区制作C ++ std :: string对象。问题是，在程序运行期间缓冲区永远不会改变。我对std::string(const char *buf,size_t buflen)调用的分析是，正在复制字符串，因为在创建字符串后缓冲区可能会更改。这不是这里的问题。有没有解决这个问题的方法？
编辑：我正在处理二进制数据，所以我不能只传递char *s。此外，从总是扫描NULL到std::string避免使用，我将有大量开销。
对我的应用程序进行的分析表明，它在字符串分配上花费了近5％的CPU时间。在很多地方，我都是通过64MB char缓冲区制作C ++ std :: string对象。问题是，...
二进制数据？停止使用std :: string并使用std::vector<char>。但这不能解决您复制它的问题。根据您的描述，如果这个巨大的64MB缓冲区永远不会改变，那么您实际上不应该使用std :: string或std::vector<char>，这都不是一个好主意。您确实应该传递一个const char *指针（const uint8_t *将更能描述二进制数据，但在幕后它是同一回事，而忽略了符号问题）。传递指针及其size_t长度，或将指针与另一个“结束”指针传递。如果您不喜欢传递单独的离散变量（指针和缓冲区的长度），请构造一个结构来描述缓冲区并让每个人都使用它们：
如果字符串不会改变，并且如果保证其寿命比使用字符串更长，那么请不要使用std::string。
没有便携式解决方案。如果您告诉我们您使用的是什么工具链，那么也许有人会知道您的库实现特有的技巧。但是在大多数情况下，string_ref<T>析构函数（和赋值运算符）将释放字符串内容，并且您无法释放字符串文字。 （对此并非没有例外，实际上，小的字符串优化是跳过取消分配的常见情况，但这是实现细节。）
似乎使用const char*而不是const char *是您的最佳选择。但是，您还应该考虑如何使用字符串。从char指针到std::string对象的隐式转换可能正在进行。例如，这可能在函数调用期间发生。
自C ++ 17起，std::string可能是您的选择。可以从裸C字符串（有或没有长度）或std::string_view中进行初始化。
尽管没有约束，但是data（）方法返回的是一个以零结尾的字符串。