Применение искинов - шоссе империализма (Стенгазета русификаторов ИТ)

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

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

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

Страница: 1

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

1

  • Автор: Лис [О]
  • Сочувствующий
  • Лис [О]
  • Зарегистрирован: 2017-03-25
  • Приглашений: 0
  • Сообщений: 1030
  • Уважение: [+0/-3]
  • Позитив: [+1/-0]
  • Провел на форуме:
    4 дня 23 часа
  • Последний визит:
    2019-07-17 09:23:07
Уткин написал(а):

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

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

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

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

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

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

0

2

  • Автор: MihalNik
  • Участник
  • Зарегистрирован: 2017-08-17
  • Приглашений: 0
  • Сообщений: 1120
  • Уважение: [+9/-1]
  • Позитив: [+7/-0]
  • Провел на форуме:
    21 день 10 часов
  • Последний визит:
    2025-01-22 01:39:46
Лис написал(а):

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

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

0

3

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

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

0

4

  • Автор: rst256
  • Участник
  • Зарегистрирован: 2017-09-15
  • Приглашений: 0
  • Сообщений: 104
  • Уважение: [+2/-0]
  • Позитив: [+0/-1]
  • Провел на форуме:
    1 день 6 часов
  • Последний визит:
    2020-11-21 18:26:14
utkin написал(а):

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

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

0

5

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

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

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

0

6

  • Автор: MihalNik
  • Участник
  • Зарегистрирован: 2017-08-17
  • Приглашений: 0
  • Сообщений: 1120
  • Уважение: [+9/-1]
  • Позитив: [+7/-0]
  • Провел на форуме:
    21 день 10 часов
  • Последний визит:
    2025-01-22 01:39:46
utkin написал(а):

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

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

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

0

7

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

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

0

8

  • Автор: Павиа
  • Участник
  • Зарегистрирован: 2017-10-23
  • Приглашений: 0
  • Сообщений: 386
  • Уважение: [+3/-0]
  • Позитив: [+2/-3]
  • Провел на форуме:
    18 дней 1 час
  • Последний визит:
    2021-04-01 13:43:30

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

0

9

  • Автор: utkin
  • Созидатель языка Валентина-2
  • Зарегистрирован: 2017-07-27
  • Приглашений: 0
  • Сообщений: 1105
  • Уважение: [+2/-0]
  • Позитив: [+4/-0]
  • Провел на форуме:
    11 дней 18 часов
  • Последний визит:
    2019-07-19 07:12:54

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

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

0

Страница: 1