Вопрос по ViewMapOfFile

[f.hump]

map_data=map_data1;

ну, это меняет значение поинтера но не меняет данных.

поэтому, нужно сделать CopyMemory map_data на вспомогательный буффер, потом CopyMemory map_data1 на map_data и в заключение CopyMemory вспомогательный буффер на map_data1.

[qip2005]

Спасибо f.hump.
А кто может предложить как прочитать нормально вторую половину файла? Реально уже мыслей нет. Получается что если файл допустим весит 2*64*1024+2=131074 байт , то первую половину считываю без вопросов, т.е. первые 65537 байт, вторая половина начинается 65538 байта, что не кратно гранулярности и я теряю серьёзный кусок инфы. Как можно это решить?

[f.hump]

как прочитать нормально вторую половину файла?

Я думаю стоит честно просчитать ситуацию на бумажке. Для начала хотя бы для приведенного примера (131074 байт). Посмотреть сколько байт откуда, куда и когда копировать, не стесняться использовать указатели. Стоит помнить, что чтение данных проиходит блоками по 64к и только со смещений кратных ганулярности. Еще, думаю, нужно понять, что задача не про то "как прочитать вторую половину файла", а про то как правильно скопировать данные. Когда получится пример, посмотреть, что нужно улучшить/изменить для того чтобы работало в общем случае.
Только так.

[rpy3uH]

мне кажется проще промэпить весь файл и сделать что-то в духе

for(i=0; i<(filesize/2); i++)
{
   tmp = mapdata[i];
   mapdata[i] = mapdata[filesize-i-1];
   mapdata[filesize-i-1] = tmp;
}

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

fp = filesize/2+1;// (если размер нечётный, то байт в середине остаётся на месте)
for(i=0; i<(fp); i++)
{
   tmp = mapdata[i];
   mapdata[i] = mapdata[fp+i];
   mapdata[fp+i] = tmp;
}

и к тому лучше если нужна именно оптимизация, то лучше создать один объект файлового мэпинга, чем два.
если вы думаете что копирование цикле это долго, я могу вас успокоить: функции CopyMemory и memcpy копируют память также

[f.hump]

функции CopyMemory и memcpy копируют память также

если я правильно помню, то CopyMemory пользуется REP MOVSB, что определенно быстрее чем цикл.
Плюс ТС говорит о ситуации, когда загрузить весь файл в память невозможно, либо слишком ресурсорсемко.

[rpy3uH]

Сообщение от f.hump

то CopyMemory пользуется REP MOVSB, что определенно быстрее чем цикл.

не всегда быстрее, проверено на личном опыте

[f.hump]

2 гру3ин

А можно пример, чтобы тоже на личном опыте проверить.

[rpy3uH]

конкретных примеров у меня нет, года три назад при написании лабы по алгоритмизации я хотел похвастаться перед преподом, сделал копирование через ассемблерную вставку через rep movsb, я получил уменьшение скорости. и к тому же всё заивисит от размеров данных и модели процессора.
вот тесты http://www.ezdoum.com/upload/cache/bandwidth.pdf

вообще многие методы оптимизации которые были описаны в старых книгах по асму уже не работают на современных процах. Плюс есть куча дополнительных условий ускоряющих или замедляющих скорость выполнения иструкций, например, наличие искомых данных в кэше и т.д. и т.п. А если программа на С++ то ещё зависит от того что там сгененирует компилятор

[f.hump]

А... Известная тема.
Для тех кто хочет знать подробности читаем это:
http://www.intel.com/Assets/PDF/manual/248966.pdf


Ч:
Заодно сам почитал.
Пишут, что если кто хочет отжать максимум из REP MOVS, для объемов больше 16 байт, имеет смысл выравнивать память по 16-ти байтной границе.