Подтвердить что ты не робот

Классы контейнеров STL с поддержкой диска?

Мне нравится разрабатывать алгоритмы с использованием STL, однако у меня есть эта повторяющаяся проблема, когда мои наборы данных слишком велики для кучи.

Я искал замены для замены STL-контейнеров и алгоритмов, которые поддерживаются на диске, то есть структуры данных, хранящиеся на диске, а не куча.

Друг недавно указал мне на stxxl. Прежде, чем я буду слишком вовлечен в это... Имеются ли какие-либо другие замены STL на диске, которые я должен рассмотреть?

ПРИМЕЧАНИЕ. Меня не интересуют постоянство или встроенные базы данных. Пожалуйста, не упоминайте boost:: serialization, POST ++, Библиотека реляционных шаблонов, Berkeley DB, sqlite и т.д. Я знаю об этих проектах и ​​использую их, когда они подходят для моих целей.

UPDATE: несколько человек упомянули файлы сопоставления памяти и использовали пользовательский распределитель, хорошие предложения BTW, но я бы указал им на обсуждение здесь где Дэвид Абрахам предлагает, чтобы пользовательские итераторы были необходимы для контейнеров с резервной копией. Значение подхода пользовательского распределителя вряд ли будет работать.

4b9b3361

Ответ 1

Я реализовал нечто очень похожее. Реализация итераторов является наиболее сложной задачей. Я использовал boost:: iterator_facade для реализации итераторов. Используя boost::iterator_facade, вы можете легко адаптировать любые кэшированные в структуры данных диска для использования интерфейса контейнера STL.

Ответ 2

Мне никогда не приходилось делать что-то подобное, но возможно, вы сможете сделать то, что хотите, написав пользовательский распределитель, который использует файлы с отображением памяти, чтобы вернуть ваши данные.

См. boost:: interprocesses для документов в их простой в использовании реализации файлов с отображением памяти, эта статья доктора Доббса для подробного обсуждения написания распределителей и эта колонка IEEE Software для описания проблема и пример кода.

Ответ 3

Если (как вы пишете) вас не интересует постоянство, самым простым решением было бы увеличить размер вашей кучи и использовать возможности виртуальной памяти вашей операционной системы. Часть кучи, которая не будет вписываться в физическую память вашего компьютера, будет выгружена на диск, что даст вам именно то, что вы хотите: обычный доступ STL к данным, которые часто хранятся на диске. Операционная система позаботится о кэшировании наиболее используемых страниц в физической памяти и выселении на диск тех, которые вы не используете много. Ваш код останется прежним, и вы можете увеличить его производительность, просто добавив больше физической памяти.

Чтобы увеличить размер вашей кучи, проверьте параметры своей операционной системы, такие как ulimit (1) в Unix-системах и свойства системы - Advanced - Performance - Advanced - виртуальная память в Windows XP. Если вы столкнулись с 32-битным пределом 4 ГБ, рассмотрите возможность перехода на 64-битную архитектуру или компиляцию вашей программы на 64 бит.

Ответ 4

Я не знаю много о предмете, но возможно ли было бы написать STL-подобный интерфейс для файла с отображением памяти?

edit: Этот подход может быть подходящим, если вы пытаетесь получить определенную часть огромного файла. Если вы пытаетесь сделать что-то со всем файлом, вы, вероятно, сгенерируете огромное количество ошибок страницы, когда будете читать в незашифрованных частях файла.