Необходимо прочитать в оп память ( отобразить ) файлик в 16 Гб Вопрос собственно как? Даже не спрашивайте зачем) Естественно что все надо под x64 а Точнее Windows7 64
Voodoo была бы возможность кусками... код требует буфер, в этом то и трабла. гляну что можно сделать.
spa Как обычно регает ISR и мониторим #PF/GP("#AV"). При попытке обращения изменяем буфер, адреса или селекотры, подобно как расширяется стек в NT.
spa Если тебе нужно выполнять трансляцию table[dword]->dword, то можно либо сортировать индексы, либо делать несколько проходов загружая таблицу по частям и обрабатывая только загруженные индексы. А по другому в случае случайного доступа и отсутствии 16Гб оперативной памяти задача будет решаться только теоретически, а на практике "не дождётесь!"
Black_mirror давайте теоретический вариант) я гляну. Вообще доступ то не случайный, но программа обработчик написана не мною, поэтому я не знаю алгоритма. Поэтому мне надо организовать для нее буфер в 16 гб )
мапите небольшое окно. доступ оформить через функцию. (в случае С++ -> в виде класса + оператор индекса.) старшая часть адреса в файле шевелит окно по файлу, младшая - адрес в окне. вообще, непонятна нужда мапить такие большие куски одновременно. сверхбыстродействующая база данных? так ведь все равно на диск оно сбросится не сразу. проще кэшировать в памяти и сбрасывать в отдельном потоке на диск. ну а по 100% защите от потери - сами понимаете, против лома нет приема.
spa тут ещё важна цена вопроса. спокойно посчитайте, не выйдет ли дешевле купить систему с 16гб, чем возюканье? и может в дальшейшем это сильно окупиться по производительностью, по сравнению с работой кусочками)
wsd 1 раз надо выполнить... там билдинг с одного формата в другой, хотя про покупку оперативы для дом компа еще в размере 12 гб, можно подумать
qqwe Причина, в том что код требует char* buf и загруженный в него файл целиком, а переписывать тот код, ой как не хочется, верней ОЙ КАК НЕ ХОЧЕТСЯ. Поэтому надо костыль написать )
конечно, надо смотреть на код, но если нужно выполнять трансляцию - вероятно, не так уж сложно. если в формате нет ссылок - то достаточно просто. и вообще, если код ест char*, то переписать его как сказал qwwe - не такая уж проблема, наверное.
spa > Причина, в том что код требует char* buf и загруженный в него файл целиком Может быть можно переопределить оператор обращения к элементам буфера? char& operator[](int); В переопределенном операторе реализовать мапинг файла.
Ну идея клерка будет через ексепшины работать, так что для нормальной реализации её все равно достаточно большие куски памяти аллочить нужно иначе медленно будет ну примерно как прикол с наномитами если их не туды впихнуть все здоровски тормозит ... я как-то об это спотыкался
skomarov я об этом тоже думал, но надо еще разыменование перегрузить, и глянуть что будет) А вообще если сделать инлайнои и по уму, даже тормозить не должно.
*humble* Может мне кто-нибудь чисто символически объяснить, почему обычный MapViewOfFile не прокатывает? 64-битная Windows подкачивать с винта что ли разучилась?
l_inc А хз, я хоть и грозился но так и не успел попробовать. адд Пока писал, решил пробовать, вроде правда катит) завтра отлажу отпишусь.
spa Обычный маппинг — это вроде как первая мысль, которая должна возникнуть. Тут начали придумывать велосипед с обработкой исключений, когда в ОС есть уже встроенная Honda CBR1000RR. А после того, как даже Black_mirror так критически отписался, мне даже как-то стыдно стало со своими глупыми вопросами/предложениями лезть...
