Как определить конец файла?

[SSW]

Хочу из файла прочитать строки и загнать в масив.
Есть в Паскале такая функция EOF(f) в VC такой не нашел поэтому делал так:

Код:

CStdioFile fb("boardbase.ssw", CFile::modeCreate | CFile::modeNoTruncate | CFile::modeReadWrite );
strok1=1;
while  (fb.GetPosition()<fb.GetLength())
|	
  fb.ReadString(ListG1[strok1]); 
  fb.ReadString(ListG3[strok1]); 
  strok1++;
}
fb.Close;

Такой метод работал до сегодняшнего дня. Может кто знает другой метод? Как закончить цыкл?

[Гром]

while(ReadFile(...))
{


}

Все  

[RXL]

Почитай внимательно help на CStdioFile, а конкренто о методе ReadString. Наверняка он возвращает что-то, индицирующее конец файла. Быстрее всего 0.

[Антон (LogRus)]

Почитай внимательно help на CStdioFile, а конкренто о методе ReadString. Наверняка он возвращает что-то, индицирующее конец файла. Быстрее всего 0.

вот выдежка из MSDN.
Return Value
A pointer to the buffer containing the text data. NULL if end-of-file was reached without reading any data; or if boolean, FALSE if end-of-file was reached without reading any data.
по руски:
возврышяет указатель на буфер содержащий данные.
возврышает NULL если был достигнут конец без чтения данных; или в булевом виде, FALSE если был достигнут конец без чтения данных.

[Гром]

Вот уж не понимаю зачем класами MFC пользоваться когда CreateFile ReadFile и WriteFile под боком - удобнее ведь, а строку по \r\n в конце всегда определить можно - и работает на порядок быстрее - проверено.

[Антон (LogRus)]

Вот уж не понимаю зачем класами MFC пользоваться когда CreateFile ReadFile и WriteFile под боком - удобнее ведь, а строку по \r\n в конце всегда определить можно - и работает на порядок быстрее - проверено.

По своей сути CStdioFile не класc MFC это классовая оболочка fopen и прочего и класической stdio.h с другой стороны CreateFile ReadFile и WriteFile более коректно использовать в привении к Windows, а не стандарные io т.к. CreateFile ReadFile и WriteFile поддерживают такие понятия как права доступа, способы разделения и прочее, кроме того умеет открывать диски, директории, тома дисков, консольные буфера, ленточные накопители, комуникационные ресурсы, mailspots и pipe.
И это всё мы получили двумя минутами ковыряния в MSDN!      

[SSW]

М-м-да!
Похоже мой способ всетаки работает.
Или компилятор глючит или лажа в чем-то другом.
Надо поспать.
Спасибо за советы.

[Антон (LogRus)]

Правильно я вот уже в 10:00 вечера лёг! и проснулся в 7:00 утра (на работе  ) правда иногда приходилось просыпатся. Я смотрел что тутачкинового и далше спать.

Кстати наши способы должны работать, а именно:

Код:

while  (fb.ReadString(text))
{    
  strok1++; 
  ......
} 

Хотя проверить не могу я всё больше Borlandom интерисуюсь и VC в глаза не видел.

[NeilPryde]

По своей сути CStdioFile не класc MFC это классовая оболочка fopen и прочего и класической stdio.h

Цитата из MSDN: CStdioFile. This class is derived from CFile.
И еще одна: CFile. This class is the base class for Microsoft Foundation Classes (MFC).
MFC – все равно подключится, не зависимо от сути.

[awolf]

А еще проще использовать функции fopen, fread, fwrite ... В этом наборе есть такая функция кака feof. Просто и удобно. Поддерживается также форматированный ввод/вывод в файлы.  

[Lex]

fopen, fread, fwrite etc. лучше использовать если пишешь платформонезависимый код (ну или предполагается, что когда-нить он может быть таким). Если писать исключительно под Win, то лучше использовать CreateFile, ReadFile/WriteFile. ну или CFile и его потомков.

[awolf]

Lex, речь идет не о том, что лучше или хуже использовать - это уже вопрос личных предпочтений и необходимости. Речь идет об определении конца файла. Я предложил использовать feof.

[Lex]

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

[awolf]

В этом я абсолютно согласен. Но личные предапочтения не мешают выдвинуть версию ответа.  

[awolf]

Кстати, Lex, от тебя люди не услышали пока ни одной версии определения "конца" файла. Может поделишься "тайным знанием" своим?  

[Lex]

Моя версия мало чем отличается от тех, что здесь высказаны.
если у меня используется fopen/fread/fwrire то это feof().
Если CreateFile/ReadFile, то по количеству считанных байт и сравнению с запрошенным количеством.
Если MFC, то по тому, что вернула CFile::ReadFile()

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

[awolf]

[Джон]

Держите, на больше времени нет (к сожалению):

EOF() = начало файла + длинна файле

псевдо код для усех (VC BCB etc)

размер буфера = ::GetFileSize(hFile, NULL);
// hFile конечно берём из CreateFile(...)

*буффер = new byte[размер буфера]
unsigned int  скока прочитал;
ReadFile(hFile, буффер, размер буфера, &скока прочитал,NULL);

потом в буффере ищешь \r\n (Win) или только \r(Linux) и запихиваешь
их в массив

Ещё, если точно известно, что это текстовый файл, то концовка может быть '\0'
но это не обязательно

[awolf]

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

[Антон (LogRus)]

Класс каких только техник не увидишь. Просматривая ответы на казалосьбы простой вопрос!

[awolf]

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

[Джон]

к awolf
правильно, чтоб совсем чисто было (блин старею)
эт делается в CreateFile с FILE_SHARE_READ (например)

хотя на практике... если разве что на мулти платформе
но замечание правильное

зы Закрыть конечно тоже надо опосля CloseFile(hFile);

[Джон]

к awolf
Эт точно - на практике (честно) ни разу проблем не было.
Но раз на то пошло то надо и такие вещи делать:

char *psz = new char[256];

if(psz==NULL)
{
    // Нету 256 байт памяти!!! помогите!!!!
     throw(0);
}

но кто это делает? я - никогда

[awolf]

Есть же функции блокировки/разблокировки регионов файлов LockFile/UnlockFile

[Гром]

Есть много типов блокировки - но файл шарить не надо никогда, только в случае необходимости, так как обычно 99.99% случаев файл не нужен больше никому.
Блокировать соответственно тоже не обязательно.

Джон - ты б зарегился что ли, удобнее ведь

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

[awolf]

Есть еще вариант - это создание временной копии файла и, соответственно, работа с временной копией.
Насчет проверки выделения памяти - даже в винде есть момент, malloc возвращает NULL. Так что проверка всегда актуальна.
А на микроконтроллерах - так и подавно.

[Джон]

Грому,
ну дык, я ж в высокие то материи-то и не лезу. В виду имелось то, что практически
нарабатывал. У 90% (вру) юзеров стоят винды, а про другое и знать не хотят.
А потому за то и  платят. Как ни крути, а жить на что-то надо. Не знаю как у других,
(может расскажут?)  а у нас за дополнительные строчки кода не платят. Главное
быстрее и проще, если надёжно тоже не возбраняется. А как начнёшь "умничать" так считай, что попал...
Ладно, а то разболтался, да ещё не по теме.
Насчёт "зарегиться" - чесно - очень хочу, но пока нет времени - точнее стабильного
расписания. IMHO самый классный сайт и форумы у вас тут. Парни почти всегда в тему советуют, а не умничают, как на некоторых. Если чёто в MSDN не нахожу к вам бегу сразу. Как и в этот раз... Но и на старуху как говорится... У меня вообще-то любовь к "железу" чисто платоническая (поэтому и сомнения на счёт регистрации, смогу-ли быть полезным?). Но волею судеб пришлось вот. Кстати, извиняюсь сразу за "не в тему", просто пользуюсь случаем. Не знал в какой форум вопрос задать, ключевые слова WriteFile() LPT TimeOut. При простой записи в порт, если он не принимает, висит WriteFile() аж 90 секунд - стабильно. Откуда такая магическая цифра берётся? Открываю CreateFile(LPT1,...,Overlapped=NULL)  те синхронно, но почему 90 сек? А не скажем 45? Да... посылается 10 байт. Вот ... может чего присоветуешь? Или пошлёшь .... ...  в правильный форум.

А зарегестрируюсь обязательно...

[awolf]

Джон, магическая цифра 90 может объясняться тем, что драйвер LPT-порта по умолчанию ставит таймаут по чтению в 90 секунд.

[awolf]

Можно попробовать использовать SetCommTimeouts для изменения этого таймаута.

[Джон]

Не фурычит, те такая же штука прокатывает с СОМ, а вот параллельный никак