Считать последнюю строку из файла

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

0

Usaga, У самого был опыт решения подобной задачи (не спрашивайте зачем). В итоге залез в исходники ReadLine у StreamReader (тогда еще исходников не было в свободном доступе) и реализовал так же, но в обратную сторону. Получилось на подобие, как предлагали вы. Мне казалось это наиболее оптимальным. Но учитывая, что текстовый файл не предназначен для чтения определенных строк и соответственно любое решению уже будет своего рода костылем, то понятие оптимальный получается достаточно неоднозначным. По быстродействию, по памяти, по времени написания кода и т.п.. И, например, считывать строки последовательно перезаписывая ими некую переменную, которая после выхода их цикла и станет последней строкой, может стать в некотором случае более оптимальным. Но я за первый вариант, ибо при почти любом размере файла он будет стабилен.

0

Сообщение от Shogun31337 В частности, если не стоят жесткие требования к производительности, то почему бы не использовать метод менее производительный, зато на порядки быстрее в реализации?

Менее производительный (менее, Карл!) - да, можно и нужно применять, если это написать намного быстрее. Но ReadAllLine().Last() - это максимально хреновый вариант.

Сообщение от Shogun31337 И раз уж зашел разговор о собеседовании, то встает вопрос - согласится ли работодатель оплачивать время, потраченное на решение задачи, на решение которой нужно 2 секунды (повторюсь, при условии, что о производительности речи не идет)

Написать нормальное решение, в данном случае, минутное дело: промотать поток назад от конца файла до первого CRLF, а потом вызвать ReadLine(). Можно буферизировать чтение через BufferedStream для поднятия производительности, благо, что это всего одна строчка кода дополнительная. Такое решение покажет работодателю, что человек умеет пользоваться головой мозга и хоть что-то понимает, а не хватает первое попавшееся средство из BCL, лишь бы выдало что-то похожее на результат.

Сообщение от sldp И, например, считывать строки последовательно перезаписывая ими некую переменную, которая после выхода их цикла и станет последней строкой, может стать в некотором случае более оптимальным.

Нет не будет. Вместо того, чтобы сразу найти нужную строку в файле и прочитать только её (благо, что её положение известно заранее - последняя в документе), такой подход будет вычитывать ВСЕ данные (про которые заранее известно, что они на хрен не нужны), создавать объекты строк, и тут же их выкидывать, ибо они не нужны, мы же последнюю ищем. Да, создание объектов и их вычистка из нулевого поколения быстра, но ведь аргументом в пользу такого решение выступает не это, а то, что данное решение уже есть в BCL. А раз есть и работает (пофигу как), то оно автоматически становится "оптимальным".

0

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

0

sldp, вы путаете оптимизацию и нормальное решение.

Добавлено через 2 минуты
Нормальное решение - читать только то, что нужно только оттуда, откуда нужно. Хреновое решение - применить любой первый попавшийся под руку готовый механизм, лишь бы, хотя бы побочно, оно выдало то, что нужно. Чувствуете разницу?

Оптимизация тут вообще не причём.

0

Usaga, Наверно так и есть. Сам бы придрался к своему комментарию будь он не мой)

0

sldp, я с вами согласен, что "грязное" решение может быть лучше "нормального" в плане времени на него потраченного. Но тут же совсем уже хрень... Ну серьёзно...

0

Usaga, Смотрите. Первая мысль - решить задачу c помощью BCL, как завещали. Потом приходит осознание, что проделывается слишком избыточная работа. И вот тот и приходит оптимизация. Нужна ли она? Или есть возможность вообще по другому реализовать доступ и хранение информации?

Добавлено через 50 секунд
Это два ответа к первому сообщению)

Добавлено через 2 минуты

Сообщение от Usaga я с вами согласен, что "грязное" решение может быть лучше "нормального" в плане времени на него потраченного. Но тут же совсем уже хрень... Ну серьёзно...

Тут да. Я в целом защищал абстрактный более медленный подход

0

Сообщение от sldp Потом приходит осознание, что проделывается слишком избыточная работа.

Ага, щаЗ. Если что-то заработало хоть как-то, то из кругозора оно сразу же выпадает. Это если совсем уже конские тормоза появляются, тогда человек за мозг профилировщик берётся. Вы слишком высокого мнения о людях)

0

Usaga, Верим в лучшее

0