Русскоязычное программирование

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Русскоязычное программирование » базовые определения » символьная обработка - 19 век


символьная обработка - 19 век

Сообщений 1 страница 9 из 9

1

Уткин написал(а):

символьная обработка - 19 век еще.  Уже давно есть возможность рассматривать строки

Я не понял что Уткин имеет в виду.
Строка - это цепочка символов.

Как Уткин сделал вывод, что у меня символьная обработка?
Почему Уткин решил, что я не пользуюсь строками?

Что значит "использовать строки" не используя символы?

Да, это верно, что у меня там перед лексемами есть "уровень символов", но его же никак не заменить на "уровень строк", т.к. смысл поменяется (и потеряется).

Отредактировано Лис (2018-05-06 08:13:08)

0

2

Лис написал(а):

Что значит "использовать строки" не используя символы?

Наверное, использовать везде строковые функции, забыв про единичные знаки и байты. Это правильный подход с точки зрения Unicode.

0

3

Именно. И там был еще автомат с магазинной памятью. Алгоритмы того времени не разбивали текст на строки, а работали со сплошным потоком байтов. Оттуда же были и головняки с указанием/вычислением местоположения ошибки. Суть - текст как линия, тогда как сейчас текст это плоскость.

0

4

utkin написал(а):

Алгоритмы того времени не разбивали текст на строки, а работали со сплошным потоком байтов. Оттуда же были и головняки с указанием/вычислением местоположения ошибки. Суть - текст как линия, тогда как сейчас текст это плоскость.

Алгоритм для преобразования смещения в байтах от начала текста в формат "номер строка:отступ от начала строки" довольно прост, так в чем же "головняк"?
Текст это и сейчас линия, а построчная обработка как раз таки устаревший тупиковый метод. Зачем разбивать текст на строки если токены могут состоять из нескольких строк (многострочный комментарий)?
Достаточно просто, работая со сплошным потоком байтов, вести отсчет текущего положения по номеру строки и отступу от ее начала.

0

5

Зачем разбивать текст на строки если токены могут состоять из нескольких строк (многострочный комментарий)?

Затем что так удобней обрабатывать. А в чем проблема в многострочном комментарии? Заводите флаг/триггер переключающий режим разбора. Вообще никаких проблем. Рассматривать нижнюю границу комментарий построчно УДОБНЕЙ. Потому что я, зная, что это комментарий, могу читать строку с конца для поиска нижней границы комментария. И в большинстве случаев это будет на порядки быстрей, чем искать маркер конца комментария сначала. Нафиг перебирать символы комментария, если это комментарий? А потом вопросы - а почему компилятор такой долгий? А потому что он читает комментарии, которые ему никуда не упали.

0

6

utkin написал(а):

А потом вопросы - а почему компилятор такой долгий? А потому что он читает комментарии, которые ему никуда не упали.

Потому что он многократно переделывает то, чего делать вообще не надо. Многострочный комментарий это вообще жуткий костыль. Даже текстовые редакторы давно умеют разрывать строки на несколько по пробелам с учётом ширины окна и только программисты ещё подгоняют окна под длину строк.

Отредактировано MihalNik (2018-05-07 09:48:10)

0

7

И я об этом. Теория и практика, по-крайней мере, в русскоязычном сегменте старовата.

0

8

Запустил профайллер.  У меня самая медленная операция это сравнение строк в словаре. Ибо всё руки не дойдут до оптимизации.
Сравнение строк занимает более 84%
Грамматический анализ 15%
А разбор комментариев в сканере 0٫12%
А разбор пробелов в сканере  0٫12%

0

9

Сравнение строк занимает более 84%

Само сравнение или их количество? Просто не может сравнение строки столько времени занимать.

0


Вы здесь » Русскоязычное программирование » базовые определения » символьная обработка - 19 век