std :: istream이 streambuf를 통해 소유권을 갖는 이유는 무엇입니까?

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; 

일을하는 실제 방법은 배경로드에 사용되는 또 다른 추상화 계층으로, 실제로 다른처럼 전화를 걸만큼 간단해야하지만 여기서 중요하지 않아. 내가 알고 싶은 무엇

내가 그것을 파괴있어 때 std::[i/o]stream<>과 관련된 std::streambuf<>가 삭제되지 않는 점을 고려 auto_ptr<> (또는 unique_ptr<>, 당신은 선택)를 돌려주는 방법이다.

나는 constructor이 소유권 의미의 전달을 나타내지 않기 때문에 std::[i/o]stream<>이 생성시 전달 된 streambuf에 대한 소유권을 가지지 않는다고 생각하고 있으며 Apache의 STDCXX 참조는 소유권의 전환을 언급하지 않으며 (stdlib 내가 인터넷에서 찾은 참조).

어떤 대안이 있습니까? FSlib 관리자가 공유 포인터의 고유 복사본을 보관할 때까지 공유 포인터를 반환하고 계속 관찰 할 수 있습니다.이 경우 FSBL은 고유 복사본과 streambuf를 파괴합니다. 도서관의 조직적 모델을 고려하면 실용적입니다. 그러나 이것은 그다지 우아하고 효율적이지 않습니다.

Boost.Iostreams를 살펴 보았습니다.하지만 스트림 자체가 유형에 강하게 붙어 있기 때문에 상황이 더욱 나빠졌습니다 (스트림 용 장치를 정의해야합니다. 템플릿 매개 변수에서). 이 문제는 스트림의 구체적인 "소스/싱크"구현을 추상화하여 스트림을 원활하게 사용하여 실행 파일 자체 내에있는 파일을 열 수 있어야하므로 Boost.Iostream을 내 라이브러리에서 사용할 수 없도록 만듭니다. 시스템의 파일 시스템에있는 파일 내부 또는 아카이브 유형 파일 내부에 저장됩니다.

이러한 문제를 처리하는 컨테이너 클래스를 작성할 수는 있지만 더 정교하게 처리해야합니다. 즉, 이미 스트림을 반환하면됩니다.

제안 사항?

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 클래스를 구현하는 방법에 보라, 그들은