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

Question

我正在为CRI Middleware的ROFS(见维基百科)等视频游戏编写某种虚拟文件系统库.我对图书馆的意图是提供访问我开发的游戏资源的自然方法,它存储可执行文件中嵌入的一些数据,一些存储在媒体上,一些存储在本地用户的硬盘上(首选项,保存游戏文件等) .

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

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管理器保留共享指针的唯一副本,在这种情况下它会破坏它的唯一副本以及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)