爲什麼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的所有權？

回答

相關問題