你好，我想向公众推荐我做一个字符串类（如std::string）的想法，该字符串类具有能够处理客户端提供的缓冲区的功能。
您预见到的危险是什么？这是经典的气味吗？ etcaetera
我的意思是这样的：
char ext[64] = {0};
my::string s(ext, my::string::acquire_RW);
size_t len = s.size();
size_t pos = s.find("zboub");
my::string s2(s); // uses true (alloc+)copy semantic here.
所以我预见到2个策略：acquire_RW和acquire_RO，允许修改ext中的字符。对于任何非const方法的RO情况，以及必须扩展缓冲区的方法中的RW个案例;它会分配＆amp;此刻只复制。
在某种程度上，my::string类型会成为char*类型的装饰器。
当然要小心不要在装饰器留给客户端之前释放外部缓冲区。
感谢您分享您的疑虑
答案 0 :(得分：1)
“良好做法”的答案很难。我会说，一般不是很好的做法，但对于一些特定的用例非常好的做法。这一切都取决于您在提供的内存的生命周期内如何信任客户端。一般来说：没有信任。在特殊情况下：好的。
有一个相当重要的事情要考虑表现明智：
您是否计划使用分配的变体字符串的隐式共享（带写入和引用计数的副本）？或者你打算使用价值语义（总是复制，永远不参考）？
在多处理器和多线程环境中，值语义是字符串的首选方式。多线程环境中必要的锁定会破坏使用隐式共享的性能提升。
请注意，即使在多线程的情况下，您的建议仍然有意义：从外部存储器到分配的变体（无需锁定），以及从那时起的值语义（也没有锁定）时，您可以完美地使用写时复制必要）。这将是最好的。
我认为你的变体在非常具体的用例中运行良好，例如你用一些字符串对一些文件进行内存映射，你不想存储这些小字符串和片段内存的副本。
但是，在一般情况下，我不会担心，只需使用std::string。
答案 1 :(得分：0)
我认为这是一个好主意，但我会坚持只读; std::string对RW非常有用，除非当然存在可以节省一些内存分配的情况。
这是一个非常优化，所以它可能不值得努力，除非你知道你的静态字符串导致你的问题。