Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пн июл 16, 2018 04:51

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.

Куда цеплять "драйвера"?
Создавать лексиконы наподобие Си-библиотек 38%  38%  [ 3 ]
Прятать внутрь интерпретатора 0%  0%  [ 0 ]
Усложнять интерпретатор 0%  0%  [ 0 ]
Использовать более одного интерпретатора 25%  25%  [ 2 ]
FORTH устроен совсем не так 38%  38%  [ 3 ]
Всего голосов : 8
Автор Сообщение
 Заголовок сообщения: От FORTH - к OS
СообщениеДобавлено: Ср апр 09, 2014 12:08 
Итак, на входе - обычный FORTH, не имеющий на борту ничего, чего бы не было необходимым для его работы (саморазвития). Нам надо расширить его некоторыми свойствами операционной системы - взаимодействием с некими устройствами, многозадачностью и прочим...
Какое направление предпочесть?

1. Создавать лексиконы наподобие Си-библиотек?
Появляется новое устройство - пишем новый лексикон (особый словарь), и все. Например, определяем слова ввода-вывода в порты, опроса семафоров и т.д. Комбинируем их в высокоуровневые слова типа "вкл/выкл".
Плюс - можно подключить что угодно.
Минус - теряется преимущество FORTH-подхода, программа становится практически неотличимой от написанной на Си.

2. Прятать внутрь интерпретатора?
Закапываем всю машинерию вглубь интерпретатора. Пользователь даже не знает, что FORTH где-то что-то химичит.
Например, так обеспечивается работа с FORTH-консолью в графических ОС и реализуется классическая многопользовательность путем переключения пользовательских областей.
Плюс - FORTH-программы просты и стандартны.
Минус - теряется способность программиста получить легкий доступ к внутренностям системы.

3. Усложнять интерпретатор?
Расширяем классический интерпретатор не свойственными ему инструментами.
Дополнительные Циклы Управления, включение новых хранилищ данных, процедур их итерпретации...
Например, целевая компиляция, заменяющая стандартную интерпретацию реакцией на определенный ввод пользователя.
Плюс - идеально подходит для изготовления нужного проблемно-ориентированного языка.
Минус - FORTH перестает быть стандартным.

4. Использовать более одного интерпретатора?
Объединить несколько FORTH-систем вместе.
Например, у меня в FOBOS есть две форт-системы, объединенные общим словарем: одна заполняет словарь необходимыми для примера определениями, другая обрабатывает Win-сообщения примера.
Плюс - каждая из систем остается простой.
Минус - взаимопроникновение нескольких FORTH-систем совершенно не проработано.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 00:14 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Варианты выбора НЕ взаимоисключающие. Поэтому результаты опроса будут неточные в пределах пересечений. :(

gudleifr писал(а):
1. Создавать лексиконы наподобие Си-библиотек?
Минус - теряется преимущество FORTH-подхода, программа становится практически неотличимой от написанной на Си.
Можно нейтрализовать, вернее, сделать преимуществом, если лексиконы будут НЕ наподобие Си-библиотек, а в стиле Форта.

Ну и конечно -
gudleifr писал(а):
4. Использовать более одного интерпретатора?
Тогда каждый из них будет проще и можно удобно переключаться! :) Трудности преодолимы.
Я сделал отдельно интерпретатор интерпретации и интерпретатор компиляции. Убралось STATE - получилось очень по-Фортовски, вернее, по-КолорФортовски(внутренности этого варианта мне нравятся намного больше, чем стандартный Форт).

Сейчас переизучаю Броуди, не на все вопросы есть ответы. В том числе по использованию лексиконов и компонент(ов).

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 00:30 
in4 писал(а):
Варианты выбора НЕ взаимоисключающие
Думаю, что в случае "пересечения" можно выбрать главное/подчиненные решения. (Например, простейший способ организации вторичной машины (4) - специальные лексиконы (1), а любая вторичная машина будет иметь нестандартный интерпретатор (3). Но говорить в этом смысле имеет смысл именно о вторичных машинах).


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 00:38 
in4 писал(а):
Можно нейтрализовать, вернее, сделать преимуществом, если лексиконы будут НЕ наподобие Си-библиотек, а в стиле Форта.
Не получится. Точнее, ни у кого до сих пор не получалось.

in4 писал(а):
Тогда каждый из них будет проще и можно удобно переключаться!
Речь не о возможности запускать более одной FORTH-системы, а о FORTH-системе, состоящей из отдельных FORTH-систем.

Вашу модель поиска мы уже обсуждали. Усложнение работы процедуры СИМВОЛ (точнее ее подпроцедуры FIND), для небольшого упрощения процедуры ВЫПОЛНИТЬ, не несет никакой языковой нагрузки, следовательно говорить тут о вторичной FORTH-машине избыточно.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 00:44 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
1. Создавать лексиконы наподобие Си-библиотек?
Если жестко "наподобие" - то 4 (как оба проголосовавших к этому времени). Но я тут Броуди пререизучаю, поэтому если лексиконы можно хотя бы Фортовские, то 1, т.к имено лексиконы в данном случае первичны.
Какие-то абстракции (== выделение общих особенностей), очевидно, должны быть!

2 и 3 - разные стороны упрятывания ценой усложнения - не Форт-стиль! По-Сишному получается. Зато современно! :(

Но приятно иметь координаты в виде 300x350 или 300.100.400 . В Rebol можно еще представление типов данных подсмотреть... ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 00:58 
in4 писал(а):
Если жестко "наподобие"...
Не переживайте, они будут подобны! В чем отличие FORTH-лексиконов от C-библиотек? В использовании халявного интерпретатора - при обилии процедур входа/выхода идущих мимо него, практически не будет играть роли. В прозрачности и понятности наследования - при большом размере программ тоже пропадет.

in4 писал(а):
2 и 3 - разные стороны упрятывания ценой усложнения - не Форт-стиль!

Почему? (2) - это единственный способ выдержать стандарт при в условиях наличия сложной аппаратно/программной среды (и, особенно, применять FORTH-методы без FORTH).
(3) - а чем Вам не угодила целевая компиляция?
Впрочем, конечно, тут вопрос о предпочтениях и "-1" по этим пунктам учитываю. Спасибо.

in4 писал(а):
Но приятно иметь координаты в виде 300x350 или 300.100.400
Ну, как бы, 300x350 вполне в духе обычной работы с фиксированной точкой, а три компонента - это уже, обычно, избыточность... Но поправить NUMBER и для этого случая - не проблема.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 01:30 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
В чем отличие FORTH-лексиконов от C-библиотек?
IMHO, в том, что используется множественное соединение простых элементов(что дает большие комбинаторные возможности, 20 ВЛЕВО БАШНЯ ТАНКА ) вместо перебора многих сочетаний вариантов (БашняТанкаВлево(20) , БашняТанкаВправо(20) ). Примеры иллюстративны. Ну и прозрачная передача параметров... ;)
Остальное - вопрос проработки компонентов и лексиконов(==интерфейсов компонентов).


(2),(3)Увеличение сложности(здесь - усложнение дерева выбора нужного алгоритма) - не по-Фортовски! По-Фортовски - IMHO - добавление слоя лесикона и нескольких новых (соизмеримых по сложности со старыми) компонентов. "Решения принимает словарь"(с).

Но, конечно, проработка нужна. Поэтому я работаю над динамической, "живой" средой, где изменив что-то в одном месте можно получить полностью отличающийся(по бинарному коду) результат. Кстати, Мур уже имеет аналогичное готовое решение - использует сброс словаря и быструю перекомпиляцию. Он ее еще ускорил хранением исходников в "прекомпилированном" виде.


300x350 - это просто пример проблемно-ориентированной структуры данных. А вот как она интерпретируется - это важно. Или усложнение интерпретатора(Си), или добавляется относительно простой обработчик в список обработчиков ввода куда-нибудь в NOTFOUND (Форт).

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 01:45 
20 ВЛЕВО БАШНЯ ТАНКА
Танк (Башня, Влево, 20)
А не один хрен?
Это красиво, когда примеры маленькие (как у Броуди).
Возможно ли так же красиво писать большие программы - не известно.

К тому же речь в теме идет не красотах проблемно-ориентированных языков, а о большом количестве интерфейсов, которые вынужден поддерживать FORTH, разрастаясь.

"усложнение дерева выбора нужного алгоритма" и "Решения принимает словарь" - это как бы одно и то же.
Но какое это имеет отношение к (2) - там зависимое от ОС "дерево" спрятано и решения принимает "даже не словарь"?
И к (3) - там "дерево" искусственно обрезается до необходимого минимума?

"300x350 - это просто пример проблемно-ориентированной структуры данных".
Проблемно-ориентированная структура данных - это оксюморон.


Последний раз редактировалось gudleifr Пт апр 11, 2014 14:31, всего редактировалось 1 раз.

Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 13:41 
Чтобы было понятнее, приведу пример:
Посмотрим на PatternForth от Родригеса: методом добавления новых лексиконов (1) он расширил FORTH ассоциативными хранилищами строк, строковыми операциями и операцией сравнения строки с шаблоном. Кому лень читать первоисточник, можете посмотреть у меня пересказ.
При всех достоинствах проекта можно отметить следующие очевидные недостатки:
* перевод разговора на обсуждение лексиконов замаскировал тот факт, что задача управления памятью оказалась, по-сути, нерешенной (мол, сами доработайте свой FORTH для работы за пределами 64Kb).
* C-подобный набор строковых операций - вещь совершенно не нужная в реальном программировании.
* предложенный язык шаблонов слишком тяжеловесен.
Попробуем посмотреть, нельзя ли применить другие методы:
(2) - упрятывание в интерпретатор. Конечно! Ведь предложенный механизм работы со строками практически делает работу FIND. Не проще ли переписать свой FORTH так, чтобы словари могли занимать более 64Kb (размещаться по-блочно) и хранить более длинные имена (с пробелами)? Можно и хеширование добавить... И все. Фортер даже не будет знать, что хранение и поиск строк что-то "весят".
(3) - нестандартный интерпретатор. Думаю, можно доказать, что подогнать язык шаблонов под стандарты FORTH-языка невозможно (можно, конечно применить стек приоритетов, как классики делали с инфиксной арифметикой). Но зачем? Интерпретатор для шаблонов давно описан и обсчитан (конечные автоматы). Так добавим к нашей FORTH-системе еще пару процедур - чтения-применения регулярных выражений. Создадим дополнительное хранилище для построенных конечных автоматов...
(4) - несколько интерпретаторов. Возвращаемся к постановке задачи. Не будет ли наш FORTH слишком тяжеловесным, получив "на борт" все эти строковые механизмы? Ведь он должен еще и что-то делать? Так может объединим две FORTH-системы: одна маленькая (на 64Kb) - для работы - и большой строковый процессор. Точнее, даже, наоборот. Большой FORTH-управлятор многими видами памяти (в т.ч. строковыми) будет содержать и рабочую FORTH-систему (которой выделит немного места и пару потоков ввода-вывода). Но, опять же, т.к. теории этого дела нет, фантазировать можно сколько угодно...


Последний раз редактировалось gudleifr Вс янв 10, 2016 12:28, всего редактировалось 1 раз.

Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 14:29 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6341
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
1)
gudleifr писал(а):
ам надо расширить его некоторыми свойствами операционной системы - взаимодействием
с некими устройствами,
многозадачностью и прочим...


gudleifr писал(а):
1. Создавать лексиконы наподобие Си-библиотек?
...
Плюс - можно подключить что угодно.


Исходя из утверждения 1), отмеченный плюс подхода является определяющим.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пт апр 11, 2014 14:38 
Хищник писал(а):
... отмеченный плюс подхода является определяющим.
Логично. Хотя, цена за написание "всего" - полный отказ от преимуществ FORTH.
И часто ли требуется "все"?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Сб апр 12, 2014 12:37 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
Танк (Башня, Влево, 20)
А не один хрен?
2 момента.
1. Видели ли вы в современных Си-(С#, Java) короткие имена? Много таких? Современные имена IMHO ооочень длинные... :(
2. Передача параметров. В Си сначала значения пакуются в параметры, чтобы передать их через точку вызова, потом они, если параметры качественные, а не количественные(множества, коды режимов и т.п.), разбираются - проходят через проверки - серии вложенных if или switch/case, чтобы выбрать нужный обработчик(ветвь алгоритма). В Форте довольно просто сразу установить нужный обработчик и сократить, таким образом, дополнительные проверки. Даже если нужно позднее связывание - обработчик будет определен позже, IMHO, часто все же можно сократить подобные проверки.
gudleifr писал(а):
Возможно ли так же красиво писать большие программы - не известно.
С этим еще продолжаю играться. На данный момент стиль программирования уже заметно изменился, теперь нарабатываю опыт.
Уже пришел к тому, что даже разрекламированный git(система контроля версий) - непоследовательный и принципиально существенно ограничен. А переделывать его никто не будет - "поддержка проектов"!
Так что,
gudleifr писал(а):
красиво писать большие программы
вообще мало кто может! :) Мы не одиноки! Но это не повод не пробовать! :)

gudleifr писал(а):
К тому же речь в теме идет не красотах проблемно-ориентированных языков, а о большом количестве интерфейсов, которые вынужден поддерживать FORTH, разрастаясь.
этот вопрос поднимется еще не раз. Пока я вижу решение - дополнительные базы данных(или даже знаний) об оборудовании и его программировании(это отдельная хорошая тема). Без этого красота маловероятна... :(
gudleifr писал(а):
"усложнение дерева выбора нужного алгоритма" и "Решения принимает словарь" - это как бы одно и то же.
Принципиально разные вещи!
Усложнение дерева - когда для выбора необходимой ветки алгоритма нужно пройти через несколько проверок условий(чуть выше в общих словах пример ситуации, могу поискать точный код)
Решение принимает словарь - использование встроенного в Форт словаря - такого большого CASE на все слова. Выбор другого словаря можно рассматривать, как здоровенный такой if, который меняет набор ключей встроенного CASE !

gudleifr писал(а):
Но какое это имеет отношение к (2) - там зависимое от ОС "дерево" спрятано и решения принимает "даже не словарь"?
вы правы, никакого, про словарь - это к части
in4 писал(а):
По-Фортовски - IMHO - добавление слоя лесикона и нескольких новых (соизмеримых по сложности со старыми) компонентов.
- более Фортовское решение этой же задачи. Вместо того, чтобы прятать внутрь интерпретатора - разделить по лексиконам.
gudleifr писал(а):
И к (3) - там "дерево" искусственно обрезается до необходимого минимума?
Вроде не обрезается, просто анализируется на этапе интерпретации/компиляции, а не на этапе исполнения (в одном из вариантов реализации. Другой вариант, тоже прятать в интерпретатор == добавить сложность с отслеживанием режимов работы, в вашем примере - будут дополнительные проверки - будем выводить в текст или в графику).

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Сб апр 12, 2014 16:12 
in4 писал(а):
1. Видели ли вы в современных Си-(С#, Java) короткие имена?
А в человеческих языках, при разговоре на сложные темы? Взять тот же немецкий - самый удобный для технических описаний, который я знаю...
Здесь FORTH-выигрыш - в меньшем количестве "промежуточных имен". Однако, уже в ANSI-94 длинных имен - навалом.
in4 писал(а):
В Си сначала значения пакуются в параметры...
Технически, тоже самое. Только в C параметры именуются, а в FORTH - вводятся вручную. Наличие/отсутствие проверок от языка не зависит. (Или Вы об автоматическом приведении типов и прототипах функций?)
in4 писал(а):
Пока я вижу решение - дополнительные базы данных(или даже знаний) об оборудовании и его программировании(это отдельная хорошая тема).
Это противоречит Основному Принципу.
in4 писал(а):
Усложнение дерева - когда для выбора необходимой ветки алгоритма нужно пройти через несколько проверок условий
Это технически оправдано. В FORTH, например, стараются сократить область поиска установкой текущего словаря.
Главное правило Броуди: сначала пытаемся считать, потом - строить таблицу, и только потом - ставить IF-ы, работает во всех языках программирования.
in4 писал(а):
Вместо того, чтобы прятать внутрь интерпретатора - разделить по лексиконам.
А в чем плюс? Вероятность того, что оно кому-то понадобится - практически нулевая. Переписать это место в кодах и перекомпилировать достаточно просто. Зачем плодить лексиконы?
in4 писал(а):
Вроде не обрезается, просто анализируется на этапе интерпретации/компиляции, а не на этапе исполнения.
Это, как хотите. Я под (3) подразумеваю именно отказ от классической FORTH-системы в пользу целевой.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Сб апр 12, 2014 19:57 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
А в человеческих языках, при разговоре на сложные темы?
Договариваются о терминологии и вводят дополнительные термины для понятий. Если цель не наукообразное запутывание собеседника, то термины короткие. И указываются только отличия. 1 к 1 соответствие с Форт-подходом.

in4 писал(а):
если параметры качественные, а не количественные(множества, коды режимов и т.п.), разбираются - проходят через проверки - серии вложенных if или switch/case, чтобы выбрать нужный обработчик(ветвь алгоритма).
gudleifr писал(а):
Наличие/отсутствие проверок от языка не зависит.
Да. Но зависит от стиля программирования. И на Си можно сделать без таких проверок. Но на Форте это сделать проще. По крайней мере, синтаксически чище.
Пример - передача параметра "тип открытия файла" - Read, Write, ReadWrite. Перед передачей параметра уже известно, какой из 3-х алгоритмов использовать. Но мы эту информацию сразу не устанавливаем, а кодируем ее (раньше я сказал - пакуем, это здесь синонимы) и передаем как параметр. Генерится код передачи параметра. В вызываемой функции мы выбираем этот параметр, затем делаем проверку (в лучшем случае одну - переход по таблице). В худшем - контроль параметра - 2 проверки на крайние значения и 2 проверки для выбора одной из 3х веток.
Если вместо передачи параметра мы установим алгоритм - код может быть совершенно аналогичный - загрузка константы в ячейку памяти(тут - в переменную), то в вызываемой функции нужно только сделать вызов функции из переменной. Получается значительное сокращение кода, особенно по сравнению с худшим случаем. Об этом я и говорил, как о сложностях с передачей параметров. Можно пойти еще дальше, но это снова новая интересная тема, которую я собираюсь обсуждать позже.

gudleifr писал(а):
Это противоречит Основному Принципу.
Напомните, пожалуйста!
А так я не знаю способа сделать драйвер без описаний. Если устройств много и разных - имеет смысл информацию представить в виде таблиц, чтоб описания были рядом и их можно было сравнивать. А потом обычное построение минимального покрытия. А что таблицы в базе данных - это просто удобно при большом количестве информации. Вот то, как наполнять и поддерживать эту таблицу - вопрос организации. Можно предложить массу вариантов. Я всерьез рассматриваю вариант разбора исходников драйверов в Линуксе для построения таких таблиц.

gudleifr писал(а):
in4 писал(а):
Усложнение дерева - когда для выбора необходимой ветки алгоритма нужно пройти через несколько проверок условий
Это технически оправдано
Если вы считаете выбор варианта "ставить IF-ы" технически оправданным.... ;) А именно этот вариант я имею ввиду, когда говорю о дереве. Я сужу по коду, который иногда почитываю в надежде найти что-то умное, но обычно при этом страшно плююсь.
Решения, которые мне нравятся - это заранее установить обработчик кода, который потом вызовется без доп. проверок. Мур идет еще дальше - решения нужно менять на этапе редактирования исходников! == Изменение алгоритма.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Сб апр 12, 2014 20:04 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
gudleifr писал(а):
А в человеческих языках, при разговоре на сложные темы?
Договариваются о терминологии и вводят дополнительные термины для понятий. Если цель не наукообразное запутывание собеседника, то термины короткие. И указываются только отличия. 1 к 1 соответствие с Форт-подходом.

in4 писал(а):
если параметры качественные, а не количественные(множества, коды режимов и т.п.), разбираются - проходят через проверки - серии вложенных if или switch/case, чтобы выбрать нужный обработчик(ветвь алгоритма).
gudleifr писал(а):
Наличие/отсутствие проверок от языка не зависит.
Да. Но зависит от стиля программирования. И на Си можно сделать без таких проверок. Но на Форте это сделать проще. По крайней мере, синтаксически чище.
Пример - передача параметра "тип открытия файла" - Read, Write, ReadWrite. Перед передачей параметра уже известно, какой из 3-х алгоритмов использовать. Но мы эту информацию сразу не устанавливаем, а кодируем ее (раньше я сказал - пакуем, это здесь синонимы) и передаем как параметр. Генерится код передачи параметра. В вызываемой функции мы выбираем этот параметр, затем делаем проверку (в лучшем случае одну - переход по таблице). В худшем - контроль параметра - 2 проверки на крайние значения и 2 проверки для выбора одной из 3х веток.
Если вместо передачи параметра мы установим алгоритм - код может быть совершенно аналогичный - загрузка константы в ячейку памяти(тут - в переменную), то в вызываемой функции нужно только сделать вызов функции из переменной. Получается значительное сокращение кода, особенно по сравнению с худшим случаем. Об этом я и говорил, как о сложностях с передачей параметров. Можно пойти еще дальше, но это снова новая интересная тема, которую я собираюсь обсуждать позже.

gudleifr писал(а):
Это противоречит Основному Принципу.
Напомните, пожалуйста!
А так я не знаю способа сделать драйвер без описаний. Если устройств много и разных - имеет смысл информацию представить в виде таблиц, чтоб описания были рядом и их можно было сравнивать. А потом обычное построение минимального покрытия. А что таблицы в базе данных - это просто удобно при большом количестве информации. Вот то, как наполнять и поддерживать эту таблицу - вопрос организации. Можно предложить массу вариантов. Я всерьез рассматриваю вариант разбора исходников драйверов в Линуксе для построения таких таблиц.

gudleifr писал(а):
in4 писал(а):
Усложнение дерева - когда для выбора необходимой ветки алгоритма нужно пройти через несколько проверок условий
Это технически оправдано
Если вы считаете выбор варианта "ставить IF-ы" технически оправданным.... ;) А именно этот вариант я имею ввиду, когда говорю о дереве. Я сужу по коду, который иногда почитываю в надежде найти что-то умное, но обычно при этом страшно плююсь.
Решения, которые мне нравятся - это заранее установить обработчик кода, который потом вызовется без доп. проверок. Мур идет еще дальше - решения нужно менять на этапе редактирования исходников! == Изменение алгоритма.

gudleifr писал(а):
А в чем плюс? Вероятность того, что оно кому-то понадобится - практически нулевая. Переписать это место в кодах и перекомпилировать достаточно просто. Зачем плодить лексиконы?
А вот это тоже очень интересный вопрос. Но я бы его рассмотрел в плане корректного взаимодействия с лексиконами при их большом количестве.
Причем со стороны разработчика, создающего и прикладную программу, и лексиконы. И пока что остановился на мнении, что необходимы средства работы с исходниками, которые в данный момент отсутствуют в современных IDE.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB