Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я Вам настоятельно рекомендую не использовать разные неэффективные и костыльные решения. Если даже у Вас мало опыта в программировании, повозитесь в отладчике с файловыми операциями, изучите FileSeek(), Вам это даст нужный ценный опыт. Просто с самого начала надо идти правильным путём, пусть неумело и с ошибками. Научитесь со временем (достаточно быстро).
Я описывал 2 варианта, оба стопроцентные и эффективные. Я описывал из своего опыта, делал быстрые и эффективные бинарные хранилища данных с прямым доступом. Если собранные данные в дальнейшем планируется обрабатывать программно, гораздо эффективнее использовать бинарные файлы.
Если с целью визуального анализа или для импорта в эксель, тогда уж нужен текстовый или csv, хотя и будет менее эффективно. Но тогда зачем нужен прямой доступ к конкретной строке? Обычно при сборе данных просто дописывают в конец. Как я писал, для перемещения назад надо просто в цикле i=[0...-N] устанавливать FileSeek(h, i, SEEK_END) и проверять байт на '\n' и '\r'.
Для бинарного файла ещё проще - от конца файла возвращаемся на нужное фиксированное число байт (размер записи) - FileSeek(h, -size, SEEK_END). Это и будет начало последней записи. И так можно перемещаться назад.
Я Вам настоятельно рекомендую не использовать разные неэффективные и костыльные решения. Если даже у Вас мало опыта в программировании, повозитесь в отладчике с файловыми операциями, изучите FileSeek(), Вам это даст нужный ценный опыт. Просто с самого начала надо идти правильным путём, пусть неумело и с ошибками. Научитесь со временем (достаточно быстро).
Я описывал 2 варианта, оба стопроцентные и эффективные. Я описывал из своего опыта, делал быстрые и эффективные бинарные хранилища данных с прямым доступом. Если собранные данные в дальнейшем планируется обрабатывать программно, гораздо эффективнее использовать бинарные файлы.
Если с целью визуального анализа или для импорта в эксель, тогда уж нужен текстовый или csv, хотя и будет менее эффективно. Но тогда зачем нужен прямой доступ к конкретной строке? Обычно при сборе данных просто дописывают в конец. Как я писал, для перемещения назад надо просто в цикле i=[0...-N] устанавливать FileSeek(h, i, SEEK_END) и проверять байт на '\n' и '\r'.
Для бинарного файла ещё проще - от конца файла возвращаемся на нужное фиксированное число байт (размер записи) - FileSeek(h, -size, SEEK_END). Это и будет начало последней записи. И так можно перемещаться назад.
даже и сказать нечего....просто facepalm
даже и сказать нечего....просто facepalm
Не думаю что издевательства уместны, человек старался и ему за это спасибо.
Да, он мог где-то допустить ошибку, забыв о том, что операция чтения сдвигает файловый указатель, а так же о главном - результат работы файловых функций в полной мере зависит от режима открытия файла.
Как по мне, главный виновник в данном случаи - это автор темы, который так и не соизволил предоставить исходный код, а просто разводит бессмысленную демагогию на высосанную из пальца тему.
даже и сказать нечего....просто facepalm
От Вас вроде и не ждали.
А Вы хотели, чтобы я полностью расписал код?
UPD: Я так и не понял, что Вас так шокировало, уж напишите, не побрезгуйте убогим. Но ок, вот максимально упрощённый код. Чтобы не переоткрывать файл с бинарного на текстовый и обратно, как я писал ранее, пусть будет менее эффективное чтение строки вместо байта, и сравнение с 0 вместо '\n' и '\r'.
Единственное, в чём ошибся: i надо начинать не с 0, упустил что файл завершается переводом строки. Не думаю, что эта мелочь заставила Вас стыдиться за меня.
Сам бы я так не делал. Надо использовать бинарный файл.Решил проблему побайтного чтения(надо было последнюю строку получать) так: