LINUX.ORG.RU

Класс-контейнер двусторонняя очередь (реализованная в файле)

 , ,


0

1

В библиотеке STL имеется контейнер deque.
Разумеется, когда создается экземпляр этого класса и используется, то данные указанного типа хранятся в оперативной памяти. Как создать класс наследник, чтобы записи в этой очереди хранились в файле на диске?
. То есть чтобы я мог использовать методы push_back(), push_front(), empty() и при этом записи помещались в файл.
Может у кого есть готовые наброски?

Это домашнее задание что ли? std::deque — шаблонный без виртуальных методов, что ты наследовать собрался? Простенькая сериализация/десериализация в файл пишется за час.

fluorite ★★★★★
()
Последнее исправление: fluorite (всего исправлений: 1)

Наследоваться от stl'ных классов нельзя, ты не знал? Бери и пиши свой. Тем более что логика работы с файловым бэкендом будет полностью другая.

anonymous
()
Ответ на: комментарий от podovalov5

Нет, тебе надо именно так. Но оно не получится, так как контейнер оперирует конкретными указателями, а файл может замаппится по любому адресу. Проще говоря, да, deque с аллокатором на mmap будет работать и хранить данные в файле, но нет, остановить процесс и запустить снова на этом файле не получится. Если нужны файлы, смотри в сторону встраиваемых СУБД, например sqlite.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Проще говоря, да, deque с аллокатором на mmap будет работать и хранить данные в файле

Можно хотя бы набросок примера? Это именно то, что мне нужно, мне нужен этот файл только во время работы процесса.

podovalov5
() автор топика
Ответ на: комментарий от podovalov5

http://en.cppreference.com/w/cpp/concept/Allocator, и не забудьте что вам придётся руками следить за освобождением, т.е. хранить информацию о выделенных блоках, при освобождении сложным образом проверять появились ли у вас пустые страницы и освобождать их, серьёзно думать о фрагментации и т.д.

Ещё раз советую забыть про std::deque и сделать свой контейнер - оно будет и проще, и эффективнее в плане как производительности, так и памяти. Храните внутри deque страниц + 2 счётчика частичной заполненности первой и последней страницы, при push'ах при необходимости новая страница выделяется анонимным mmap'ом, при pop'ах пустые страницы освобождаются, в остальных случаях push/pop это просто увеличение инкремент/декремент счётчика + placement new/вызов деструктора. Никакой фрагментации помимо двух крайних страниц, никакой головной боли и сложности, полный контроль над стратегиями выделения (размер страницы, возможность делать madvise для вытеснения не нужных сейчас страниц на диск или наоборот prefetch) и даже, если добавить ещё десяток строчек кода, возможность persistence.

slovazap ★★★★★
()
Ответ на: комментарий от podovalov5

На гитхапе есть примеры для вектора и очереди — адаптируй. Можешь посмотреть как это сделано в https://github.com/knizhnik/POST-- (см. раздел реадме где они говорят про использование STL со своими аллокаторами)

slackwarrior ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.