Почему не делает станд.:: istream принимают владение по его streambuf?
Я пишу своего рода библиотеку виртуальной файловой системы для видеоигр в подобных ROFS Промежуточного программного обеспечения CRI (см. Википедию). Мое намерение с библиотекой состоит в том, чтобы обеспечить естественные средства доступа к ресурсам игр, которые я разрабатываю, которые хранят некоторые данные, встроенные в исполняемый файл, некоторых на медиа и некоторых на жестком диске локального пользователя (предпочтения, сохраните игровые файлы, и т.д.).
Доступ к таким ресурсам должен быть столь же простым как звонящий как
std::auto_ptr defaultConfigIStream(
fslib.inputStream("self://defaultConfig.ini"));
std::auto_ptr 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<> не предполагает, что владение по streambuf передало ему на конструкцию, поскольку конструктор не представляет семантику передачи права собственности, и ссылка Apache STDCXX не упоминает transer владения (ни делает любую из stdlib ссылок, которые я нашел в Интернете).
Какие альтернативы я имею? Я мог бы также возвратить общий указатель и продолжать наблюдать его, пока менеджер FSlib не сохраняет уникальную копию общего указателя, в этом случае он уничтожил бы свою уникальную копию, а также streambuf. Это практично, рассматривая организационную модель библиотеки, но это не очень изящно, ни эффективно в этом отношении.
Я попытался смотреть на Повышение. Iostreams, но кажется, что вещи еще хуже с ним для меня, поскольку самим потокам присоединили их Типы устройства сильно к их типу (Устройство для потока должно быть определено в его шаблонном параметре). Эта проблема, кажется, делает использование из Повышения. Iostreams, невыполнимый для моей библиотеки, поскольку это должно абстрагировать далеко конкретную реализацию "источника/приемника" потоков так, чтобы потоки могли использоваться беспрепятственно для открытия файла, расположенного в самом исполняемом файле, в файле от файловой системы системы или в файле типа архивирования, например.
Я мог записать контейнерный класс, который обрабатывает эти проблемы, но я сделал бы это более чисто (т.е. просто уже возвратил бы поток; это - все, в чем должно требоваться!;).
Предложения?
1 ответ
Вы могли бы просто получить свои собственные классы потоков из 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 )