Tại sao không std :: istream giả định quyền sở hữu trên streambuf của nó?

Question

Tôi đang viết một số loại thư viện hệ thống tệp ảo cho các trò chơi video theo dạng ROFS của CRI Middleware (xem Wikipedia). Ý định của tôi với thư viện là cung cấp phương tiện tự nhiên để truy cập tài nguyên của trò chơi mà tôi phát triển, lưu trữ một số dữ liệu được nhúng trong tệp thực thi, một số trên phương tiện và một số trên ổ cứng của người dùng cục bộ (tùy chọn, lưu tệp trò chơi, v.v.) .

Tiếp cận các nguồn tài nguyên như vậy nên càng đơn giản như thực hiện cuộc gọi như

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; 

Cách thực tế làm việc thực sự là khác nhau, với một lớp trừu tượng được sử dụng để tải nền, nhưng đó không phải là quan trọng ở đây.

Điều tôi muốn biết là làm cách nào tôi có thể trả lại số auto_ptr<> (hoặc unique_ptr<>, bạn chọn) xem xét std::streambuf<> được liên kết với số std::[i/o]stream<> sẽ không bị xóa khi nó bị hủy.

Tôi đang xem xét std::[i/o]stream<> không thừa nhận quyền sở hữu đối với luồng được truyền đến khi xây dựng vì nhà xây dựng không trình bày chuyển giao ngữ nghĩa quyền sở hữu và tham chiếu STDCXX của Apache không đề cập đến quyền sở hữu. tài liệu tham khảo tôi đã tìm thấy trên internet).

Tôi có những lựa chọn thay thế nào? Tôi cũng có thể trả về một con trỏ chia sẻ và tiếp tục xem nó cho đến khi người quản lý FSlib giữ một bản sao duy nhất của con trỏ được chia sẻ, trong trường hợp đó nó sẽ phá hủy bản sao duy nhất của nó cũng như streambuf. Đó là thực tế, xem xét mô hình tổ chức của thư viện, nhưng điều này không phải là rất thanh lịch cũng không hiệu quả cho vấn đề đó.

Tôi đã thử xem Boost.Iostreams, nhưng dường như mọi thứ thậm chí còn tồi tệ hơn đối với tôi, vì bản thân luồng có các loại Thiết bị được gắn chặt với loại của chúng (Thiết bị cho luồng phải được xác định trong thông số mẫu của nó). Vấn đề này dường như làm cho việc sử dụng Boost.Iostream không khả thi đối với thư viện của tôi, vì nó cần trừu tượng hóa việc triển khai "nguồn/chìm" cụ thể của các luồng để các luồng có thể được sử dụng liền mạch để mở tệp nằm bên trong tệp thực thi, bên trong một tệp từ hệ thống tệp của hệ thống hoặc bên trong một tệp kiểu lưu trữ, ví dụ.

Tôi có thể viết một lớp chứa để xử lý các vấn đề này, nhưng tôi muốn thực hiện nó một cách rõ ràng hơn (tức là chỉ trả lại luồng đã có; đó là tất cả những gì cần!).

Đề xuất?

Answer 1

Bạn chỉ có thể tìm thấy các lớp học của riêng bạn từ istream resp. ostream, đặt bộ đệm trong hàm tạo và phá hủy nó trong trình phá hủy.

Cái gì như:

class config_istream : public std::istream { 
public: 
    config_istream(std::string name) : 
     std::istream(fslib.InputStream(name.c_str())) 
    { 
    } 

    ~config_istream() { delete rdbuf(); } 
}; 

Có một cái nhìn về cách fstream lớp học được thực hiện, họ đối phó với một vấn đề tương tự (filebuf đã bị xóa cùng với fstream)