Убить можно убить eof() ?
если же файловый поток достиг значения eof
т.е. конеца файла
то как можно сбросить это значение.
если же я перевожу укозатель позиции в файла в начало
seekp(0)
seekg(0)
то по сути значение eof должно терятся
а оно остаётся.
так вроде не должно быть.
в этом и возникла моя проблема.
пожалуйста помогите
ifstream fin("C:\\test.txt");
for( ; ; ){
while(! fin.eof()) fin >> str.c_str();
fin.seekg(0);
}
Я поставил ifstream за цыклом, но если сделать его внутри:
for( ; ; ){
ifstream fin("C:\\test.txt");
while(! fin.eof()) fin >> str.c_str();
}
то тогда всё работает верно, но медленно так как каждый раз по окончанию цикла поток разрушаается и в начале создаётся
в таком случае конечно же значение eof() каждый раз сбрасывается.. но такой подход меня не устраевает так как слишком медленная скорость а циклы и листы очень и очень большие..
Вы обратили внимание что я в первой констукции по завершению цикла while поставил указетель для чтение в начало файла fin.seekg(0); ?!
но при этом значение eof() остаётся и из файла всё время после самого первого верхнего цыкла будет считыватся послднее слово из файла...
Вот конкретный не рабочий пример:
for( ; ; ){
while(! fin.eof()) fin >> str.c_str();
fin.seekg(0);
}
Факт, не работает. Либо я чего-то не догоняю, либо в реализации STL от Borland тоже есть косяки.
Далее немного не по теме, но это важно.
Вот так:
делать нельзя.
Указатель, возвращаемый методом c_str() должен использоваться только для чтения, потому как
1) нет никакой гарантии, что выделено достаточно места под буфер для читаемой из файла строки "внутри" объекта класса AnsiString;
2) мы не знаем, как реализован класс AnsiString, может быть, он при использовании каких-либо методов/свойств создаёт новый буфер, копирует туда текст, а старый буфер мочит, и тогда при работе вышеприведённого фрагмента данные уйдут БиллГейтс знает куда, и, возможно, затрёт что-нибудь полезное, или приведёт к Access Violation;
3) это просто моветон.
_
- если так нельзя то как сделать правильно?
Если же это ошибка Борленда то как можно сделать правильно? чтобы всё работало и быстро? может есть ещё какие то способы а то эта ерунда мне срывает весь проект! :(
ведь глупо каждый раз во много тысячном цыкле открывать и закрывть поток! должен же быть выход!
ПОЖАЛУЙСТА ПОДСКАЖИТЕ! а то я уже не знаю что мне делать
- Для того что я пишу это есть самый быстрый самый оптимальный вариант.. Имеется только вот эта проблема с eof();
Я тут подумал может быть это не ошибка? может быть eof() просто указывает что конец файла был достигнут а не то что указатель находется в конце.. Он может быть где угодно. Вообще вроде способ сбить это значения должны же быть. Но как? блин я сейчас разплачусь =)) Я из-за этой ерунды не могу же забить на проект.. Пожалуйста кто нибуть помогите
xiOn, этот ifstream поддерживает произвольный доступ? (random access).
Пример из борландовской доки говорит, что поддерживает.
fin >> str.c_str();
- если так нельзя то как сделать правильно?
Надо так:
char *s = new char[1024]; // Ну или какая у тебя максимальная длина строки +1...
/* Какой-то код */
fin >> s;
str = s;
/* Ещё какой-то код */
delete []s;
Если же это ошибка Борленда то как можно сделать правильно? чтобы всё работало и быстро? может есть ещё какие то способы а то эта ерунда мне срывает весь проект! :(
ведь глупо каждый раз во много тысячном цыкле открывать и закрывть поток! должен же быть выход!
ПОЖАЛУЙСТА ПОДСКАЖИТЕ! а то я уже не знаю что мне делать
Похоже, придётся именно открывать/закрывать поток. А лучше не потоком, а функциями fopen() либо CreateFile() (imho, второй вариант предпочтительнее с точки зрения быстродействия). Только надо не забывать, что CreateFile() есть только в Win32 (т.е. не переносима на другие платформы).
Для позиционирования есть fseek() и SetFilePointer() соотвессно.
> imho, второй вариант предпочтительнее с точки зрения быстродействия
- Скорее всего с точки быстродействия оптимальнее было бы сделать с использованием буфиризации..
Если же производить считывание из одного файлового потока и запись в другой то из-за этого будут происходить задержки с посоянными перемещениями головки диска а следовательно на эти промежутки времени скорее всего обработчик процессов будет преостанавливать процесс моей программы до получения ответа о выполнении заданной операции ввода/вывода. Если же использовать другой способ с использованим буфер то по сути никаких существенных задержек быть не должно... Например с диска считываются входные данные и помещаются в память определённого размера после заполнения которого данные збрасываются в выходной файловый поток.. те сборс происходит кусками а не кусочками..
по сути это должно быть быстрее но по моим наблюдением вариант с использованием буферизации уступает некоторым другим вариантам. Вот некотарая схема стравнения что я давно составил:
---
fputs():
Строка неизменна = 5500
Строка меняется = 29641
---
ofstream
Строка неизменна = 9828
Строка меняется = 12109
---
буфер 0X1000
Строка неизменна = 7265
Строка меняется = 27656
---
буфер 0X50
Строка неизменна = 5500
Строка меняется = 27656
---
Стрка изменна и не изменна означает что я производил экспеременкт записи как простой строки
"типа эото" так и изменной с каждым новым циклом
"типа этого count+=1"
просто такие изменения в сорости вызванны разными типами переменных
например чтобы записать так
String str = "cool!";
ofstream fout("C:\\test.txt");
fout << str.c_str()
так вот такие фишки изменения типа как .c_str() IntToStr() и тд не нуждаются в использовании при одних типах записи и нуждаются при других..
например при
String str = "cool!";
FILE *fp = fopen("C:\text.txt");
fputs(str, fp);
- надеюсь что нигде не ошибся..
думаю принцип ясен
что тут .c_str() уже не требуется..
и скорость быстрее..
И вообще своими экспеременктами я заметил что файловая структура NTFS почти в полтора раза медленее чем FAT32 !!!
я сам был в шоке когда это заметил.. так что я теперь не вижу ни какого повада чтобы ставить NTFS. Так как его не понимают старые оси или файловые менеджеры типа Волков командера.
Короче думаю что вы поняли что у меня за проблемы. Если я что то не так сказал то скорее всего я что то не так понял.
> imho, второй вариант предпочтительнее с точки зрения быстродействия
- Скорее всего с точки быстродействия оптимальнее было бы сделать с использованием буфиризации..]
хех... Это и ёжику понятно. Только ручками писать нормальную буферизацию немного долго, как я понимаю из треда, elan'у не до того. Кстати, если для рабoты с файлами выбрана fopen(), то для буферизации есть setbuf() и setvbuf(). Для CreateFile(), я уверен, тоже свои методы буферизации есть.
У тебя ещё неплохие результаты получились. NTFS в общем случае медленнее FAT32 примерно вдвое. Вообще, NTFS -- хороший пример того, как Micro$oft своим вмешательством может опошлить самые хорошие информационные технологии. NTFS создана на основе IBM HPFS, которая быстрее FAT32 в эти же самые 1.5-2 раза.
1) более высокая надёжность
2) более гибкое разграничение доступа
3) "невидимая" упаковка либо шифрование данных
4) более рациональное использование дискового пространства
5) имена файлов записываются в unicode, так что никаких проблем с кодовыми страницами (попробуй-ка на русской винде95/98 прибить в config.sys строку Country=007,866,C:\WINDOWS\COMMAND\country.sys и запустить англоязычный NDD... А с NTFS таких проблем нет).
У каждого свои недостатки. Windows 2000, например, не понимает линуксовый EXT3 или IBM'овский JFS... Вместо Волкова пользуйся FAR.
Plisterone я теперь смотрю Ван Хелсинг. Но этот пост тебе не забуду:D(еще не конец фильма, поэтому не знаю, кто хуже, ты или Дракула :D). После клнца фильма вырежу коды из одной моей программы и отправлю.
Ничего не понял. Почему ты считаешь меня таким плохим? И что мне с этими кодами делать? И кто такой Ван Хелсинг, чем он знаменит в области информационных технологий?