LINUX.ORG.RU

Нельзя ничего построчно обрабатывать в реальных программах

 ,


0

1

В очередной раз прошелся по граблям.

Реальные программы получается, что надо считать как единую строку с символами перевода строк. Иначе факапы практически неизбежны.

Чуть менее, чем всегда оказывается, что вот напишешь ты, например, построчное чтение чего-то и обработку строки, ну там регэкспами допустим что-то распарсить и поменять. По быстренькому так, просто и элегантно.

А потом хренак и оказывается на практических данных, что надо было учитывать, что часть регэкспа на разных строках находится. Даже если это казалось бы невозможно было. Ну да, фактически ошибка в исходных данных, можно в Спортлото или на ЛОР жаловаться =) Но работать оно все-равно должно и вот так оно.

Проще сразу это делать.

★★★★★

Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от monk

Например, символы алфавита в идентификаторе Си могут быть в произвольном порядке, но это не значит, что идентификаторы с разным порядком символов совпадают.

monk ★★★★★
()

… регэкспами допустим что-то распарсить и поменять.

Чем быстрее о них забудете, тем быстрее научитесь другому …

anonymous
()
Ответ на: комментарий от Miguel

А в XML-based формате — зачастую эквивалентны.

В формате — нет. Парсер (хоть DOM, хоть SAX) обязан вернуть элементы в порядке, указанном в файле.

Программа, которая получила данные из XML, вправе трактовать данные как ей надо: хоть игнорировать порядок, хоть игнорировать атрибуты или даже имена элементов.

monk ★★★★★
()
Ответ на: комментарий от praseodim

Ну если у тебя логи не форматированные, то да. А так, применяй заранее оговоренный формат, когда пишешь логи, и таких проблем не будет.

Сейчас можешь разве что попробовать читать блочно. Прерывать чтение строк, когда видишь последовательность означающую начало следующих логов. У тебя там наверняка что-то типа 2021-02-03T11:22:33.123>

Aswed ★★★★★
()
Ответ на: комментарий от Aswed

Как решить задачу я сообразил, собственно тут и соображать нечего, можно несколько вариантов использовать. От самого тупого со чтением всех 20 Гб сразу в память (благо объем позволяет) и там регэкспы над этой «строкой» сразу, до некоторого усложнения алгоритма.

Что я и сделал. В принципе ничего совсем особенного, пришлось подумать и небольшой конечный автомат расписать поверх чтения строк. Несколько флагов, буферов и switch-ей.

Просто хотелось побыстрее и если так выразиться нахаляву и уже когда думал, что получилось, обнаружил факап с переносами строк.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от anonymous

У всех этих форматов есть один изъян. Они не достаточно учитывают специфику типов данных конкретных ЯП. Взять, например, JSON. Что такое «целое число» в JSON? Это целое из JavaScript? А из какой версии JavaScript? А если целевой ЯП поддерживает ограниченные целые, типа со значениями от 0 до 360, то что вернет верификатор/лексер? Вот в Аде надо будет рантайм исключение кидать. А библиотеки, которые мы все используем, которых для JSON понаписали вагон и маленькую тележку вообще знают о существовании различных ЯП? Короче, говно ваш JSON.

seiken ★★★★★
()
Ответ на: комментарий от anonymous

иерархия языков по Хомскому

Хома-хома, хомячок,
Покажи-ка свой бочок!
Нет, не покажу:
Я на нём лежу!
Benis
()
Ответ на: комментарий от seiken

Что такое «целое число» в JSON? Это целое из JavaScript?

Есть RFC 7159

Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.
monk ★★★★★
()
Ответ на: комментарий от pathfinder

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

beastie ★★★★★
()
Ответ на: комментарий от monk

Звучит как «реализации пусть сами с собой договариваются»

seiken ★★★★★
()
Ответ на: комментарий от Zhbert

Причём Хоффисер-то как раз и не миллениал, что забавно.

mertvoprog
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.