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

хотя это похоже тобой и не предполагается, но код этих функций не относится к разряду тайных знаний.

могу задать встречный вопрос: ты представляешь себе, как работают эти CreateFileMapping, MapViewOfFile? попробуй на досуге файл на пару гигов обработать по приведенной тобой схеме.

удобнее написать непортабельный, испещренный системными вызовами код? это по сравнению с пятком строк с использованием fread? 

Смешно вас слушать, ребзя. Для таких ликбезов есть интренет. Скажу лишь, что windows-приложения лучше писать используя непосредственно апишки ядра windows вместо уродливых мутантов созданных через пень-колоду с целью posix-совместимости на основе этих же апишек. Не бойтесь большого числа параметров   

Простой пример:

FILE* f=fopen("c:\\myfile","w");
    if(f)
    {
        char szLine[] = "hi\r\n";
        fwrite(szLine,strlen(szLine),1,f); 
        fclose(f);
    }

Как ты думаешь, сколько и каких байт запишется в файл? 4 байта? Не угадал. А теперь представь, что ты сохранял файл с важными данными.  Этих трансляций-то можно избежать в бинарном режиме, но это лишний раз показывает кучу лишней бороды. О быстродействии и не заикайся.

Так вот подумай, что, как и почему.    

Это сообщение отредактировал(а) nerdy_weirdie - 13.5.2008, 01:28

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

а свою смешливость и менторский тон оставь при себе. используй интернет сначала.

Добавлено через 2 минуты и 48 секунд
хорошо, что хоть исправил. 
неисправленный "простой пример" был таким:

Всё равно всё пишет и читает ядро винды. И ты по прежнему доказываешь, что лучше дергать его не напрямую, а через посредников?

Это сообщение отредактировал(а) nerdy_weirdie - 13.5.2008, 01:41

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

если ты наступил на грабли преждевременной оптимизации и тебе понравилось, то это вовсе не означает, что сие есть правильное и полезное занятие.

странно, что ты еще ассемблер не предложил, ну да ладно... о чем это мы? об ядре. так говоришь, напрямую его дергаешь?.. 
родился еще один вопрос: ты представляешь себе количество системного кода, выполняющегося при вызове, например, ReadFile? можешь поисследовать, а когда оценишь, вернись к этому "бородатому посреднику" fread и сопоставь. точно не скажу, но полагаю, что посредник будет и по объему и по времени выполнения меньше 1% от общего кода. все те же грабли стучат нам по лбу.

Ты все до одного свои аргументы просто выдумываешь? И так упёрто.. Тебе ведь опытный человек пишет. CRT полностью основана на winapi.
Сомневаюсь, что ты мне хоть спасибо за просвещение скажешь, но объясню:
fopen вызывает CreateFile (\microsoft visual studio 8\vc\crt\src\open.c, line 388)
fwrite вызывает  WriteFile (\Microsoft Visual Studio 8\VC\crt\src\write.c, line 297)
И так далее.
Обрати внимание, сколько там кода и вызовов.

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

Это ты похоже все свои аргументы выдумываешь.


И что опытный человек хорошего написал?


Больше скажу, так или иначе, все функции работают с ядром ;-) nerdy_weirdie, ты слышал такие слова как переносимость, кроссплатформенность?


1. И часто профессионалы так делают?
2. Быстрее, проще и приятнее не значит лучше.
2. На том конце всё равно придется собирать по-частям (данные не отправятся большим куском).


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


Зачастую при программировании fopen, fwritе и пр. ещё много раз заворачивают.


Это сообщение отредактировал(а) ptr - 13.5.2008, 08:59

Hi all
И не надоело вам пересчитывать пальцы на руке - у кого их больше, тот и круче?
Хотя принципиально я все таки согласен - на АПИ оверхеда будет меньше-ИМХО
Однако при передаче по сети это совсем не критично......

Это сообщение отредактировал(а) Олег2005 - 13.5.2008, 12:11

Никогда не надоест 

Это сообщение отредактировал(а) ptr - 13.5.2008, 17:41

нет

не обязательно
ключевое слово TSO

Ну да, погорячился   Скажу аккуратнее: большая часть функций работает с ядром  


Сегментация то всё равно происходит, только на другом уровне.

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

вот у меня есть функции для приема и передачи файлов.. там в них используется пара самописных функций, но все интуитивно понятно:

и прием

Я в C++ не профи, но мое ИМХО - всегда лучше использовать кроссплатформенные функции сразу, чем потом переписывать код для другой системы.

Может пригодиться. У самого  была проблема считки бинарника 



Это сообщение отредактировал(а) cmlwt - 23.6.2008, 16:25