为什么std :: istream不对其streambuf拥有所有权? [英] Why doesn't std::istream assume ownership over its streambuf?

问题描述

我正在使用CRI Middleware的ROFS之类的方式为视频游戏编写某种虚拟文件系统库(请参见

I am writing some sort of virtual file system library for video-games in the likes of CRI Middleware's ROFS (see Wikipedia). My intention with the library is to provide natural means of accessing the resources of the games I develop, which store some data embedded in the executable, some on the media and some on the local user's hard drive (preferences, save game files, etc).

访问此类资源应该像拨打电话一样简单

Access to such resources should be as simple as making a call like

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;

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

The actual way of doing things is actually different, with another abstraction layer used for background loading, but that's not important here.

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

What I want to know is how can I return that auto_ptr<> (or unique_ptr<>, you choose) considering that the std::streambuf<> associated with the std::[i/o]stream<> is not deleted by it when it's destroyed.

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

I am considering std::[i/o]stream<> doesn't assume ownership over the streambuf passed to it upon construction as the constructor doesn't present transfer of ownership semantics and Apache's STDCXX reference doesn't mention transer of ownership (nor do any of the stdlib references I've found on the internet).

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

What alternatives do I have? I might as well return a shared pointer and keep watching it until the FSlib manager keep a unique copy of the shared pointer, in which case it would destroy its unique copy as well as the streambuf. That's practical, considering the library's organizational model, but this isn't very elegant nor efficient for that matter.

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

I've tried taking a look at Boost.Iostreams, but it seems things are even worse with it for me, as streams themselves have their Device types strongly attached to their type (the Device for a stream has to be defined in its template parameter). This problem seems to make the use of Boost.Iostreams unfeasible for my library, as it needs to abstract away the concrete "source/sink" implementation of the streams so that streams can be used seamlessly to open a file located inside the executable itself, inside a file from the system's file system or inside an archive-type file, for example.

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

I could write a container class that handles these issues, but I'd rather do it more cleanly (i.e. just return the stream already; that's all it should need! ;).

建议?

推荐答案

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

You could just derive your own stream classes from istreamresp. ostream, set the buffer in the constructor and destroy it in the destructor.

类似的东西:

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一起删除)

Have a look on how the fstream classes are implemented, they deal with a similar problem (filebuf has to be deleted together with fstream)

这篇关于为什么std :: istream不对其streambuf拥有所有权?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！