c++ - 为什么std::istream不对其streambuf拥有所有权？

我正在为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;

实际的处理方式实际上有所不同，另一个抽象层用于后台加载，但这在这里并不重要。

我想知道的是，考虑到与auto_ptr<>关联的unique_ptr<>在销毁时并未被删除，我该如何返回std::streambuf<>(或您选择的std::[i/o]stream<>)。

我正在考虑std::[i/o]stream<>不假定对构造时传递给它的streambuf拥有所有权，因为构造函数没有提供所有权语义的转移，并且Apache的STDCXX引用没有提及所有权的转移(我也没有任何stdlib引用)在互联网上找到)。

我有什么选择？我不妨返回一个共享指针并继续观察它，直到FSlib管理器保留该共享指针的唯一拷贝，在这种情况下，它将破坏其唯一拷贝以及流缓冲区。考虑到图书馆的组织模型，这很实用，但这在这方面不是很优雅也不有效。

我尝试看过Boost.Iostreams，但对我来说情况似乎更糟，因为流本身将其Device类型牢固地附加到其类型上(流的Device必须在其template参数中定义)。这个问题似乎使我的库无法使用Boost.Iostreams，因为它需要抽象化流的具体“源/接收”实现，以便可以无缝地使用流来打开位于可执行文件本身内部的文件，例如，来自系统文件系统的文件内部还是存档类型的文件。

我可以编写一个处理这些问题的容器类，但是我宁愿做得更干净(即，只需返回流；这就是它所需要的!!)。

有什么建议吗？

最佳答案

您可以只从istream resp派生自己的流类。 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一起删除)

关于c++ - 为什么std::istream不对其streambuf拥有所有权？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2083163/