为什么 std::istream 不承担对其 streambuf 的所有权？

Question

我正在为 CRI Middleware 的 ROFS 之类的视频游戏编写某种虚拟文件系统库（请参阅 Wikipedia）。我使用库的目的是提供访问我开发的游戏资源的自然方式，其中存储了一些嵌入在可执行文件中的数据，一些在媒体上，一些在本地用户的硬盘驱动器上（首选项，保存游戏文件等） .

访问这些资源应该像拨打电话一样简单

std::auto_ptr<std::istream> defaultConfigIStream(
    fslib.inputStream("self://defaultConfig.ini"));
std::auto_ptr<std::ostream> defaultConfigOStream(
    fslib.outputStream("localappdata://config.ini"));

// Copies default configuration to local user's appdata folder
defaultConfigIStream >> defaultConfigOStream;

实际的做事方式其实不一样，另外一个抽象层用于后台加载，不过这里不重要。

我想知道的是，考虑到与std::[i/o]stream<> 关联的std::streambuf<> 在销毁时不会被它删除，我该如何返回auto_ptr<>（或unique_ptr<>，您可以选择）。

我正在考虑 std::[i/o]stream<> 不承担在构造时传递给它的 streambuf 的所有权，因为构造函数不存在所有权转移语义，并且 Apache 的 STDCXX 参考没有提到所有权转移（也没有任何我在互联网上找到的 stdlib 参考）。

我有什么选择？我还不如返回一个共享指针并继续观察它，直到 FSlib 管理器保留共享指针的唯一副本，在这种情况下，它会破坏其唯一副本以及 streambuf。考虑到图书馆的组织模型，这很实用，但在这个问题上这不是很优雅也不是很有效。

我试过看一下 Boost.Iostreams，但对我来说，情况似乎更糟，因为流本身的设备类型与其类型密切相关（流的设备必须在它的模板参数）。这个问题似乎使我的库无法使用 Boost.Iostreams，因为它需要抽象出流的具体“源/接收器”实现，以便可以无缝地使用流来打开位于可执行文件本身内部的文件，例如，在系统文件系统中的文件或归档类型文件中。

我可以编写一个容器类来处理这些问题，但我宁愿做得更干净（即已经返回流；这就是它所需要的全部！;）。

建议？

Answer 1

您可以从istreamresp 派生自己的流类。 ostream，设置缓冲区 在构造函数中并在析构函数中销毁它。

类似：

class config_istream : public std::istream {
public:
    config_istream(std::string name) : 
      std::istream(fslib.InputStream(name.c_str())) 
    {
    }

    ~config_istream() { delete rdbuf(); }
};

看看fstream类是如何实现的，它们处理类似的问题（filebuf必须与fstream一起删除）