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

我正在为CRI Middleware的ROFS（参见Wikipedia）之类的视频游戏撰写某种虚拟文件系统库。我对图书馆的意图是提供访问我开发的游戏资源的自然方式，这些资源存储一些嵌入可执行文件中的数据，一些存储在媒体上，一些存储在本地用户的硬盘上（偏好设置，保存游戏文件等）。为什么std :: istream不承担其streambuf的所有权？

访问这些资源应该尽可能拨打电话一样

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<>（或，你选择），考虑到与std::[i/o]stream<>相关的std::streambuf<>时，它的破坏不是由它删除。

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

我还有什么替代方案？我不妨返回一个共享指针并持续观察它，直到FSlib管理器保留共享指针的唯一副本，在这种情况下，它将销毁其独特副本以及流缓冲区。考虑到图书馆的组织模式，这很实际，但这并不是非常优雅而且没有效率。

我试着看看Boost.Iostreams，但它似乎对我来说更糟糕，因为流本身的设备类型强烈地依附于它们的类型（流的设备必须定义在其模板参数中）。这个问题似乎使得使用Boost.Iostreams对我的库不可行，因为它需要抽象出流的具体“源/汇”实现，以便可以无缝地使用流来打开位于可执行文件本身内的文件，例如，在来自系统文件系统的文件内部或归档类型文件内部。我可以写一个处理这些问题的容器类，但我宁愿更干净地做（即只是返回流;这就是它应该需要的！）。

对此提出建议？

来源

2010-01-17 Guilherme Vieira

你可以从istream或者只是派生自己的流类。 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一起删除）

来源

2010-01-18 00:13:21 MartinStettner

是的，正如我所说的问题的结尾，我想我必须这样做。我只是想知道是否有一些更简单的方法来做到这一点XD谢谢 – 2010-01-18 00:16:54

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

回答

相关问题