// открытие файла как mapping
// возвр. 0 в случае ошибки
// fn - имя файла (ввод)
// nach - начальный адрес mapped view (вывод)
// razmer - размер файла (вывод)
int OtkritFileMap(const char*const fn, LPVOID &nach,int &razmer)
{
int result;
HANDLE hFile,hMapObj;BOOL b;
hFile=CreateFile(fn,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_FLAG_NO_BUFFERING|FILE_FLAG_SEQUENTIAL_SCAN,
NULL);
razmer=GetFileSize(hFile,NULL);
if (!hFile)
return 0;
hMapObj=CreateFileMapping(hFile,NULL,PAGE_READONLY,0,0,NULL);
b=CloseHandle(hFile);
if (!hMapObj)
{
result=GetLastError();//ERROR_ALREADY_EXISTS
return 0;
}
nach=MapViewOfFile(hMapObj,FILE_MAP_READ, 0,0,0);
b=CloseHandle(hMapObj);
if (!nach)
{
result=GetLastError();
return 0;
}
return 1;
}
// закрывает map-файл
// nach - начальный адрес mapped view (ввод)
void ZakritFileMap(LPCVOID nach)
{
BOOL b=UnmapViewOfFile(nach);
}
Использование mapping
Прошу помощи у тех, кто знает как пользовать маппингом при чтении из файла? Если можно, то с примерами, или с ссылками где можно про это почитать(желательно на руссом).
Заранее спасибо!!!
Заранее спасибо!!!
вроде так: сначала идет CreateFile, потом CreateFileMapping или OpenFileMapping и следом MapViewOfFile. в итоге получишь начальный адрес отображенного файла, с ним и надо работать, т.е. перемещаться и т.д. если ты собираешься читать всегда одно и тоже число байт или ассоциировать указатель с определенными данными(т.е. сделаешь указателем на определенную структуру), то надо конечно использовать маппинг, в других случаях проще ReadFile. а вообще смотри мсдн.
[QUOTE=pnz]Прошу помощи у тех, кто знает как пользовать маппингом при чтении из файла? Если можно, то с примерами, или с ссылками где можно про это почитать(желательно на руссом).
Заранее спасибо!!![/QUOTE]
Когда получаешь начальный адрес mapped view можешь использовать его для чтения байт как будто это указатель на строку. Только не забудьте его сохранить для последующего вызова ZakritFileMap!
P.S. Для чтения содержимого файла важна задача. Для быстрого чтения map-файл не лучшее решение. Во-первых, map-файл привязан к ОС (в Unix его нет), во-вторых, его использование возлагает функции буферизации чтения на саму ОС. Т.е. можно самому продумать буферизацию при чтении файла и эта функция будет работать быстрее, чем map-файл.
Заранее спасибо!!![/QUOTE]
Код:
Когда получаешь начальный адрес mapped view можешь использовать его для чтения байт как будто это указатель на строку. Только не забудьте его сохранить для последующего вызова ZakritFileMap!
P.S. Для чтения содержимого файла важна задача. Для быстрого чтения map-файл не лучшее решение. Во-первых, map-файл привязан к ОС (в Unix его нет), во-вторых, его использование возлагает функции буферизации чтения на саму ОС. Т.е. можно самому продумать буферизацию при чтении файла и эта функция будет работать быстрее, чем map-файл.
[QUOTE=michael_is_98]P.S. Для чтения содержимого файла важна задача. Для быстрого чтения map-файл не лучшее решение. Во-первых, map-файл привязан к ОС (в Unix его нет), во-вторых, его использование возлагает функции буферизации чтения на саму ОС. Т.е. можно самому продумать буферизацию при чтении файла и эта функция будет работать быстрее, чем map-файл.[/QUOTE]
Вряд ли можно придумать "буферизацию" быстрее, чем это реализует сама ОС. По сути, это не буферизация, а тот же механизм, что используется при свопинге. Содержимое давно не неиспользованных страниц сбрасывается в файл, причём только тогда, когда эти страницы нужны другим - сможешь самостоятельно реализовать подобную схему? В случае с отображением файлов на память используются аппаратные механизмы процессора - исключение отказа страницы, что и обеспечивает эффективную работу механизма.
Вряд ли можно придумать "буферизацию" быстрее, чем это реализует сама ОС. По сути, это не буферизация, а тот же механизм, что используется при свопинге. Содержимое давно не неиспользованных страниц сбрасывается в файл, причём только тогда, когда эти страницы нужны другим - сможешь самостоятельно реализовать подобную схему? В случае с отображением файлов на память используются аппаратные механизмы процессора - исключение отказа страницы, что и обеспечивает эффективную работу механизма.
[QUOTE=cheburator]Вряд ли можно придумать "буферизацию" быстрее, чем это реализует сама ОС. По сути, это не буферизация, а тот же механизм, что используется при свопинге. Содержимое давно не неиспользованных страниц сбрасывается в файл, причём только тогда, когда эти страницы нужны другим - сможешь самостоятельно реализовать подобную схему? В случае с отображением файлов на память используются аппаратные механизмы процессора - исключение отказа страницы, что и обеспечивает эффективную работу механизма.[/QUOTE]
Все идет от задачи...
Для конкретной задачи можно реализовать быстрое чтение даже без использования FileMap. Например, я для своей задачи использовал FileMap, чтение C-функциями (fread), чтение низкоуровневыми функциями windows (из <io.h>), потоковый ввод-вывод. И пришел к выводу, что важно не столько, какие функции используются, сколько качество этих функций (которое определяется используемым компилятором) и продуманная буферизация. Я отказался от FileMap, когда нужно было побайтово читать файл. При этом приходится каждый раз смотреть, не вышел ли ты за границы файла (не превысил ли размер). Надобность в подобной проверке отпадает когда программист сам организует буферизацию, идущую от задачи.
Все идет от задачи...
Для конкретной задачи можно реализовать быстрое чтение даже без использования FileMap. Например, я для своей задачи использовал FileMap, чтение C-функциями (fread), чтение низкоуровневыми функциями windows (из <io.h>), потоковый ввод-вывод. И пришел к выводу, что важно не столько, какие функции используются, сколько качество этих функций (которое определяется используемым компилятором) и продуманная буферизация. Я отказался от FileMap, когда нужно было побайтово читать файл. При этом приходится каждый раз смотреть, не вышел ли ты за границы файла (не превысил ли размер). Надобность в подобной проверке отпадает когда программист сам организует буферизацию, идущую от задачи.