您好，我想就我做一个字符串类（如std::string）的想法向公众进行调查，该类具有能够处理客户端提供的缓冲区的功能。
你预见到的危险是什么？是经典的味道吗？等等
我的意思是这样的：
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.
所以我预见了两种策略：这将允许修改acquire_RW或不修改字符。在任何非常量方法的情况下，以及必须扩展缓冲区的方法的情况下；它只会在此时分配和复制。acquire_ROextRORW
在某种程度上，my::string类型变成了类型的装饰器char*。
当然要小心不要在装饰器作为客户要求留下之前释放外部缓冲区。
感谢您分享您的担忧
“良好实践”的答案是困难的。我想说，一般来说不是很好的做法，但对于某些特定的用例来说是很好的做法。这一切都取决于您对所提供内存的生命周期的信任程度。总的来说：不信任。在特殊情况下：好的。
考虑性能方面有一件相当重要的事情：
您是否计划对分配的字符串变体使用隐式共享（写入时复制和引用计数） ？或者你打算使用值语义（总是复制，从不引用）？
在多处理器和多线程环境中，值语义是字符串的首选方式。使用隐式共享的性能增益被多线程环境中必要的锁定所破坏。
请注意，即使是多线程的，您的建议仍然可能有意义：从外部内存到分配的变体时，您可以完美地使用写时复制（不需要锁定），并且从那时起使用值语义（也不需要锁定）。这将是最好的。
我想您的变体在非常特定的用例中运行良好，例如，您使用大量字符串对一些文件进行内存映射，并且您不想存储这些小字符串和片段内存的副本。
但是，在一般情况下，我不会担心，只需使用std::string.
我认为这是个好主意，但我会坚持只读；std::string对 RW 来说非常好，除非当然有可以节省一些内存分配的情况。
虽然这是一个相当大的优化，所以它可能不值得付出努力，除非你知道你的静态字符串会给你带来问题。