[опять C++] Класс с заковыркой

А какой инструкцией процессора пакман съедает монстра?

Сорри, решил не читать, слишком много :)

нажрался что ли?

>St_MPA3b *** (*) (11.04.2009 5:02:59)

А тебе в это время больше заняться нечем?

Как нечем? Я баги на багзиллу КДЕ постю.

То, что тебе нужно называется memory mapped file.  К ним есть много различных интерфейсов.  Win32 и POSIX предоставляют API для mapped files.  Если тебя интересует сугубо C++, то смотри в сторону boost::iostreams::mapped_file: http://www.boost.org/doc/libs/1_38_0/libs/iostreams/doc/index.html

Использовать как-то так:

#include <boost/iostreams/stream.hpp>
#include <boost/iostreams/stream_buffer.hpp>
#include <boost/iostreams/mapped_file.hpp>

namespace io = boost::iostreams;

typedef io::stream<io::mapped_file_source>         my_stream;
typedef io::stream_buffer<io::mapped_file_source>  my_streambuf;

int main() {
    my_streambuf buf("big_input_file.bin");  // неформатированный ввод через stream_buf интерфейс
    my_stream    my_in(&buf);

    std::istream & in = my_in;  // форматированный ввод через istream интерфейс
}

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

при неважном времени отклика: каждый раз открываем файл, пересчитываем слова в нём, возвращаем нужное.

при неважно сколько объёме памяти, но не подгрузке целиком:

при первом обращении делаем что-то вроде пар

номер слова --- положение в файле (индекс).

номера слов можно взять подряд идущими или каждое 10-ое к примеру.

короче, сложная задача какая-то

> То, что тебе нужно называется memory mapped file.

Не факт: под 32-битной ОС шибко большой файл не мапнется. А вот тупо делать seek+read на каждый operator[] - вполне нормальное решение. Будет тормозить - надо будеть дальше думать, как разгонять: можно mmap кусками делать или кешировать или ещё что-нибудь изобрести.

ну индекс то тебе все равно придётся делать. а уж как потом доставать данные - через read() или через отображаемые файлы - это уже не важно. все равно в кеш полезешь.

// wbr

А что, без индекса совсем никак? Разве нельзя сделать, чтобы обращение к myclassarr[n] выглядело так:

double getv(int n)
{
  double vv;
  file.seekg(0); //перемещаемся в начало файла
  for(int i=0;i<n;++i) file >> vv; //читаем n слов
  return vv; //и возвращаем последнее прочитанное слово
}

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

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

И да, можно вообще B+ деревья использовать.

Оптимизация вообще не интересует. Хотелось бы, чтобы оно вытаскивало N-ное слово просто вернувшись в начало файла и отсчитав бы N слов (то бишь N раз сделав file >> tmp)

1. Это надо было в девелопмент постить, а не в толксы.

2. Идеи "надо файл замаппить, а не seek-ать" мне непонятны. Ядро кэширует вокруг того, что сикнуто, разве не так?

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