Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Убить можно убить eof() ?

1.9K
02 июля 2004 года
xiOn
78 / / 16.03.2004
У меня возникла проблема..
если же файловый поток достиг значения eof
т.е. конеца файла
то как можно сбросить это значение.
если же я перевожу укозатель позиции в файла в начало
seekp(0)
seekg(0)
то по сути значение eof должно терятся
а оно остаётся.
так вроде не должно быть.
в этом и возникла моя проблема.
пожалуйста помогите
1.9K
02 июля 2004 года
xiOn
78 / / 16.03.2004
Вот конкретный не рабочий пример:
Цитата:

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() остаётся и из файла всё время после самого первого верхнего цыкла будет считыватся послднее слово из файла...

294
02 июля 2004 года
Plisteron
982 / / 29.08.2003
Цитата:
Originally posted by xiOn
Вот конкретный не рабочий пример:
 
Код:
ifstream fin("C:\\test.txt");
for( ; ; ){
while(! fin.eof()) fin >> str.c_str();
fin.seekg(0);
}


Факт, не работает. Либо я чего-то не догоняю, либо в реализации STL от Borland тоже есть косяки.

Далее немного не по теме, но это важно.
Вот так:

 
Код:
fin >> str.c_str();

делать нельзя.

Указатель, возвращаемый методом c_str() должен использоваться только для чтения, потому как
1) нет никакой гарантии, что выделено достаточно места под буфер для читаемой из файла строки "внутри" объекта класса AnsiString;
2) мы не знаем, как реализован класс AnsiString, может быть, он при использовании каких-либо методов/свойств создаёт новый буфер, копирует туда текст, а старый буфер мочит, и тогда при работе вышеприведённого фрагмента данные уйдут БиллГейтс знает куда, и, возможно, затрёт что-нибудь полезное, или приведёт к Access Violation;
3) это просто моветон.
_
1.9K
04 июля 2004 года
xiOn
78 / / 16.03.2004
fin >> str.c_str();
- если так нельзя то как сделать правильно?
Если же это ошибка Борленда то как можно сделать правильно? чтобы всё работало и быстро? может есть ещё какие то способы а то эта ерунда мне срывает весь проект! :(
ведь глупо каждый раз во много тысячном цыкле открывать и закрывть поток! должен же быть выход!
ПОЖАЛУЙСТА ПОДСКАЖИТЕ! а то я уже не знаю что мне делать
1.9K
04 июля 2004 года
xiOn
78 / / 16.03.2004
> Выбери другой класс потока.
- Для того что я пишу это есть самый быстрый самый оптимальный вариант.. Имеется только вот эта проблема с eof();
Я тут подумал может быть это не ошибка? может быть eof() просто указывает что конец файла был достигнут а не то что указатель находется в конце.. Он может быть где угодно. Вообще вроде способ сбить это значения должны же быть. Но как? блин я сейчас разплачусь =)) Я из-за этой ерунды не могу же забить на проект.. Пожалуйста кто нибуть помогите
294
06 июля 2004 года
Plisteron
982 / / 29.08.2003
Цитата:
Originally posted by elan
xiOn, этот ifstream поддерживает произвольный доступ? (random access).


Пример из борландовской доки говорит, что поддерживает.

294
06 июля 2004 года
Plisteron
982 / / 29.08.2003
Цитата:
Originally posted by xiOn
fin >> str.c_str();
- если так нельзя то как сделать правильно?


Надо так:
char *s = new char[1024]; // Ну или какая у тебя максимальная длина строки +1...
/* Какой-то код */
fin >> s;
str = s;
/* Ещё какой-то код */
delete []s;

Цитата:

Если же это ошибка Борленда то как можно сделать правильно? чтобы всё работало и быстро? может есть ещё какие то способы а то эта ерунда мне срывает весь проект! :(
ведь глупо каждый раз во много тысячном цыкле открывать и закрывть поток! должен же быть выход!
ПОЖАЛУЙСТА ПОДСКАЖИТЕ! а то я уже не знаю что мне делать


Похоже, придётся именно открывать/закрывать поток. А лучше не потоком, а функциями fopen() либо CreateFile() (imho, второй вариант предпочтительнее с точки зрения быстродействия). Только надо не забывать, что CreateFile() есть только в Win32 (т.е. не переносима на другие платформы).
Для позиционирования есть fseek() и SetFilePointer() соотвессно.

1.9K
06 июля 2004 года
xiOn
78 / / 16.03.2004
Спасибо за совет!
> 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. Так как его не понимают старые оси или файловые менеджеры типа Волков командера.
Короче думаю что вы поняли что у меня за проблемы. Если я что то не так сказал то скорее всего я что то не так понял.
294
07 июля 2004 года
Plisteron
982 / / 29.08.2003
Цитата:
Originally posted by xiOn
> imho, второй вариант предпочтительнее с точки зрения быстродействия
- Скорее всего с точки быстродействия оптимальнее было бы сделать с использованием буфиризации..]


хех... Это и ёжику понятно. Только ручками писать нормальную буферизацию немного долго, как я понимаю из треда, elan'у не до того. Кстати, если для рабoты с файлами выбрана fopen(), то для буферизации есть setbuf() и setvbuf(). Для CreateFile(), я уверен, тоже свои методы буферизации есть.

Цитата:
И вообще своими экспеременктами я заметил что файловая структура NTFS почти в полтора раза медленее чем FAT32 !!!


У тебя ещё неплохие результаты получились. NTFS в общем случае медленнее FAT32 примерно вдвое. Вообще, NTFS -- хороший пример того, как Micro$oft своим вмешательством может опошлить самые хорошие информационные технологии. NTFS создана на основе IBM HPFS, которая быстрее FAT32 в эти же самые 1.5-2 раза.

Цитата:
я сам был в шоке когда это заметил.. так что я теперь не вижу ни какого повада чтобы ставить NTFS.


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.

294
07 июля 2004 года
Plisteron
982 / / 29.08.2003
Цитата:
Originally posted by elan
Plisterone я теперь смотрю Ван Хелсинг. Но этот пост тебе не забуду:D(еще не конец фильма, поэтому не знаю, кто хуже, ты или Дракула :D). После клнца фильма вырежу коды из одной моей программы и отправлю.


Ничего не понял. Почему ты считаешь меня таким плохим? И что мне с этими кодами делать? И кто такой Ван Хелсинг, чем он знаменит в области информационных технологий?

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог