как можно быстро прочитать весь файл целиком? я знаю как читать через 

fopen("c:\\1.txt", "rb");
fread(Bytes, 1024, 1, flash);
...

но как мне узнать в таком случае размер файла в байтах?

читаться должня файлы BitMap (.bmp)

можно показать кодом как это делается??

как вариант...

Не проверял, но думаю что если этот код _stranger_ переписать с использованием ifstream, то будет выигрыш в скорости чтения

А по-моему, как раз наоборот...
За счет чего будет этот выигрыш в скорости, можно поинтересоваться?

А использование fstream и метода rdbuf() не подойдет?

Добавлено через 1 минуту и 12 секунд

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


Xenon, _stranger_, пасибо за помощь!!!  

Щас попробовал, с размером получилось всё, а вот фишка в другом высочила...

мой огрызок кода выглядит так:


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


а там ещё куча всего должна быть!!!

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

сохранял так:

вполне возможно, она там есть, просто вы используете указатель на char, и компилятор естественно считает что вы передаете ему строку, и все действия с вашим указателем производит как со строкой(те до первого попавшегося нуль-символа).

Что делать. Ну про мессадже бокс ничего не скажу, не понимаю, что вы хотели изобразить  Картинка в него не выведется. А в файл сохранять надо точно также как и читали, к примеру fwrite()

Возможно этот примерчик тебе поможет?

Добавлено через 7 минут и 17 секунд
Только не забудь после использования освободить память выделенную под заголовок фаила и его BitMap массив...
тут конечноже нету никакого освобождения памяти это предусмотрено другой функцией...

Kipter, как загружать битмаппы в прогу я знаю, мне в данной ситуации надо получить все его байты... 
zkv, попробую так.... а в мессадж боксе я хотел просто увидеть ту же пакасть (содержимое файла) что и через EditPlus... а именно бредовые символы и много-много квадратиков... 

Добавлено через 12 минут и 16 секунд
zkv, получилось то что хотел! fwrite() то что надо!!! 

закрываю тему...  

За счет более оптимального алгоритма чтения.

Вот результаты замеров применения метода read для буфера в 64*10^6 байт

ifstream::read        fread
------------------------------------
1   1406                 1515
2   1484                 1422
3   1391                 1515
4   1454                 1406
5   1406                 1438
6   1422                 1453
7   1485                 1453
8   1453                 1422
9   1469                 1453
10 1484                 1469
-----------------------------------
ср. арифметическое
-----------------------------------
1445,4        1454,6

выражено ~ 10^-3 секундах

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

Интересно было бы сверить скорости работы методов чтения класса CFile и ifstream

Это сообщение отредактировал(а) dizzy1984 - 25.4.2007, 13:12

Выгода? Где эта выгода? Средние числа отличаются меньше, чем на 1%, все разбросы в диапазоне случайных.

Я и сам пришел к тому же выводу, читай пост выше

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


А я говорю, что ее вообще нет. Хотя, с темой давно все выяснили, заканчиваем.

Хм...
Столь сильное желание несоглашаться побудило меня на другие эксперименты.
Главный опасный момент в предыдущих результатах заключался в том, что как средство измерения я использовал ::GetTickCount(), точность которого была где-то 1*10^-3. Кроме того у меня был слишком большой буфер. Теперь я вооружился абсолютным средством, а именно счетиком TSC и связанной с ним RDTSC, кроме того я увеличил время чтения. Похоже я действительно "пролетел" с точностью измерений.
Теперь результаты с лихвой подтверждают мое первоначальное суждение.
92170230 для fstream::read против 613031179 для fread. Время чтения с помощью fstream::read ~5 раз меньше fread. Такие вещи полезно знать для программ работающих с большими файлами.

Вот сам код.

мне кажется или участники не в равных условиях?

Э, не понял... За каким гуком здесь стоят seekg и rewind? Постоянно считывать одни и те же 64К?
Дак их система закэширует по ей одной понятному принципу... Данный код ничего реального не отображает.

Ну вот я сделал и свои замеры. Код следующий был у меня (MinGW)



Файл 42-метровый, если что.
"std::cout << buf[77]" для облома компилятору оптимизировать вызов функции, так как без этого он явно пытается это делать.
Собрано в release.

Итак, результаты:


Разницу в 5 раз во времени не вижу.

Реализация замера времени в данном случае - QueryPerformanceFrequency/QueryPerformanceCounter.

Добавлено через 7 минут и 27 секунд

Что ты здесь имел в виду? Отсутствие ios::binary? Или что-то другое?


Это сообщение отредактировал(а) JackYF - 26.4.2007, 17:01

Чтобы не прочитать за конец файла


Через чур интеллектуально для системы



Принимается. Изменил на другой



Режим Release.
Первый цикл пробегает за какую-то долю секунды.
За время второго я успеваю сосчитать до 25-ти


Чего мелочиться? давай уж хотя бы 10^4

Вобщем я бы мог поспорить на счет правильности вывода и точности счетчиков, но дело-то в том что у меня разница заметна "на глаз". 
Я пробую на vs6.0, но и на 8-ке у меня все летало. Хорошо помню как считал построчно и обработал каждую строку в файле 80-метров за 3 секунды. 
Может дело в различной реализации?

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

Это сообщение отредактировал(а) dizzy1984 - 26.4.2007, 20:53

Забавно. Давай подсчитаем количество считанных тобой байт. За одно считывание у нас читается приблизительно 64К.
Считываний у тебя 10000. Итого мы считываем 10000*64К = 10*64М = 640 Мб.
Ты говоришь, что это происходит за долю секунды?

По имеющимся у меня сведениям, скорость 640 Мб/с не имеет ни один жесткий диск.

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

ребят, вас чё понесло-то??  

Лично я увидел фразу



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

JackYF, вы тут делагогию развели по пустому! я сделал что хотел... за эт пасибо... я не просил самый быстрый способ...  

Нет, не по пустому... Это довольно-таки принципиальный вопрос - вопрос скорости работы С-файлов и С++-потоков.

В данном случае скорость не роляет, это да.

Если оффтопик, то можно выделить в отдельную тему...

Высокая скорость работы первого цикла объяснялась отсутствием процесса чтения. Метод read читал первые 4-ре байта и встречал символ ctrl+z, а посколько файл был открыт как текстовый (  ) воспринимал это как конец файла и ставил статус "все плохо". все последующие 10000-1 итерации работа метода обрывалась где-то в самом начале на проверке статуса.
Я добавил std::ios::binary в конструктор потока. Время срабатывания метода ofstream::read стало больше, чем fread от 1.5ра до где-то 10-ти раз.
Я зря спорил с тобой, ты был прав с самого начала.
Извини.


P.S Мне было интересно и я попробовал также CStdioFile::Read. В большинстве случаев он шел очень близко к fread.

вот-вот. я про это и говорил.

Ага, понятно. Я тогда заметил отсутствие ios::binary, но забыл про такую фишку чтения текстовых файлов...
Тогда многое становится ясным.



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

Вот теперь тему можно точно закрывать.