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;

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

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

我正在考虑{{1}}并不假设在构造时传递给它的streambuf的所有权，因为构造函数不提供所有权语义转移，而Apache的STDCXX引用没有提到所有权转移（也没有我在互联网上发现的stdlib引用。）

我有哪些替代品？我不妨返回一个共享指针并继续观察它，直到FSlib管理器保留共享指针的唯一副本，在这种情况下它会破坏它的唯一副本以及streambuf。考虑到图书馆的组织模式，这很实际，但对于这个问题，这不是很优雅也不高效。

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

我可以写一个处理这些问题的容器类，但我宁愿更干净地做（也就是刚刚返回流;这就是它应该需要的！）。

建议？

Answer 1

您可以从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一起删除）

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

1 个答案: