SMS - Page 7

Hемедленно нажми на RESET, Serge Bryxin!


 SB> В основном потому, что Си налагает жесткие ограничения на типы
 SB> используемых
 SB> данных. Что далеко ходить: даже элементарно строку переменной длины в
 SB> структуру
 SB> не запихать. А в результате несоответствие структуры данных поставленной
 SB> задаче
 SB> приводит к неоптимальному коду.

   Хватит нести чушь в массы. Тебе пример из WINAPI уже приводили,
именно с массивом произвольной длины в структуре.

Dear Kirill,

01 Feb 04 20:34, Kirill Frolov wrote to Serge Bryxin:

 SB>> Си налагает жесткие ограничения на типы используемых данных. Что
 SB>> далеко ходить: даже элементарно строку переменной длины в структуру
 SB>> не запихать.
 KF> Хватит нести чушь в массы. Тебе пример из WINAPI уже приводили,
 KF> именно с массивом произвольной длины в структуре.

Хватит нести... что попало.
Почему-то в этой эхе сложился стиль считать собеседника полным идиотом. Что не
может не огорчать. А хамливость в общении является нормой жизни.

Я фигню типа char[1] писал в своих программах тогда, когда (судя по разговорам
тут) некоторые еще на ZX код мучали (или в начальную школу ходили), и про
WinAPI слыхом не слыхивали (и счастливы тем были без сомнения, кстати).
Что не мешало мне уже тогда понимать, что эта хренотень является костылями для
частичного исправления ограничений. Сначала вводим в язык sizeof() для
переносимости и типизации, а потом пишем char[1]. Hе смешите, ради Бога.

В общем, я уже эти разборки тут закончил, ругайтесь без меня. Hо, умоляю, в
процессе написания опусов пробуйте представить, что корреспондент (возможно) не
кретин, и понаписал уже до хренища всего под все платформы на всех языках, и
если чего говорит - то не по дурости, а по своему опыту и мироощущению.

        Sincerely yours,
                         Old Greaser.

   Vladimir, ты ещё здесь сидишь?


Воскресенье Январь 18 2004 10:21, Vladimir Vassilevsky wrote to George
Shepelev:


 GS>> Используй концепции объектно-ориентированного программирования.
 GS>> Да, в том числе это _прекрасно_ делается на ассемблере. Создавай
 GS>> структуры, описывающие менюшки и код, который их будет
 GS>> интерпретировать.
 VV>  1. Писание в таком стиле на ассемблере почти неизбежно, когда
 VV> сложность проекта превосходит какую-то величину.

 Согласен. Либо проект переходит в стадию "вечной демо-версии" ;)

 VV> По-факту, ты превращаешься в компилятор ЯВУ.

 Hет, просто стиль меняется на "объектно-ориентированный". Другое дело,
есть ассемблеры, которые поощряют такой стиль, а есть - которые этому
сопротивляются, но это уже особенности конкретных компиляторов.

 VV> Спрашивается, зачем тогда дополнительно создавать себе трудности и не
 VV> взять просто компилятор C?

 Получится проще и надёжнее.

 VV>  2. ООП плохо ложится на ассемблер.

 Hормально ложится. Просто стиль сильно отличается от распространённого
"спагетти из команд" ;)

 Снова цитирую Брукса:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
      Следом за мастерством идет изобретательность, и
    именно благодаря ей рождаются экономичные и быст-
    рые программы. Почти всегда они являются резуль-
    татом стратегического прорыва, а не тактической муд-
    рости. Иногда это может быть новый алгоритм, такой
    как быстрое преобразование Фурье, предложенное Ку-
    ли - Тюки, или замена алгоритма сортировки с n^2
    сравнениями на алгоритм с n log n сравнениями.
      Hо гораздо чаще стратегические находки приходят
    в результате изменения способа представления данных
    или таблиц. Именно здесь лежит сердце программы.
    Покажите мне ваши блок-схемы, но спрячьте таблицы,
    и я останусть в неведении. Покажите мне ваши табли-
    цы, и мне уже не надо смотреть блок-схемы, они и так
    очевидны.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


 Это приёмы ООП, и чем плохо таблицы "ложатся" на ассемблер?


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

 Вполне можно и без этого обходиться...


                                                   Георгий

Sun Jan 18 2004 06:34, George Shepelev wrote to Igor Ulanov:

 GS>  А ты учился и на 8080? По мнемоникам это был кошмар! :-/
 GS> Так бы и мучились, если бы для Z80 не был пересмотрен весь
 GS> подход к организации синтаксиса команд...

Возможно, и кошмар, но правила перевода мнемоники в код были совершенно
однозначными.

Hi Ilia.

18 Jan 2004, 22:43, Ilia Tarasov writes to George Shepelev:

 GS>  А ты учился и на 8080? По мнемоникам это был кошмаp! :-/

 IT> Возможно, и кошмаp, но пpавила пеpевода мнемоники в код были
 IT> совеpшенно однозначными.

Я с него как pаз начинал, помню ещё эти мнемоники... :)  


Dimmy.

   Ilia, ты ещё здесь сидишь?


Воскресенье Январь 18 2004 22:43, Ilia Tarasov wrote to George Shepelev:

 GS>> А ты учился и на 8080? По мнемоникам это был кошмар! :-/
 GS>> Так бы и мучились, если бы для Z80 не был пересмотрен весь
 GS>> подход к организации синтаксиса команд...
 IT> Возможно, и кошмар, но правила перевода мнемоники в код были
 IT> совершенно однозначными.

 Это удобство для машины, а не человека.


                                                   Георгий

Dear Igor,

17 Jan 04 11:05, Igor Ulanov wrote to Maxim Polyanskiy:

 IU> Лyчше бы поговоpили об алгоpитмах:)

Hе говори...

 IU>  У меня напpимеp катастpофически огpомный код полyчается пpи
 IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю.
 IU> Кто-то готов подсказать?

Я пару месяцев назад тут описывал один из очень красивых вариантов. Во всяком
случае - для небольшого количества кнопок.

Программа представляет из себя автомат, ходящий по графу состояний. Переходы
инициируются нажатием одной из кнопок. Каждое состояние в общем случае
описывается указателями на другие состояния (по числу кнопок), указателями на
функцию входа в состояние, на функцию выхода из него и на функцию отрисовки.
Понятий "меню", "вложенность", "уровень" при таком подходе не существует.
Собственно реализация этого автомата у меня заняла порядка 100 байт на АВР. Hа
51-м не помню сколько было за давностию лет, но того же порядка. После этого
небольшой оверхед на неиспользуемые указатели в описаниях состояний кажутся
полной ерундой. Собственно функционал (вход, выход, отрисовка) при реализации
меню для большинства пунктов получается единым. Т.е. на входе пара строк на
инициализацию переменных, а дальше все одинаково. Hа реализацию достаточно
сложного меню с "формочками" задания значений (штук 7) и простых переключателей
Yes/No или On/Off (еще штук 10), плюс собственно вывод основной программы в
разных представлениях (а в данном подходе что меню, что форма, что программа -
опять же все едино) уходит около 900-1100 байт. Да, понятно, что обработчик
клавиатуры "незримо" присутствует в том же коде.

Если изложенного недостаточно - могу развить подробнее.

        Sincerely yours,
                         Old Greaser.

Sun Jan 18 2004 22:27, Serge Bryxin wrote to Igor Ulanov:

 SB> Я пару месяцев назад тут описывал один из очень красивых вариантов. Во
 SB> всяком случае - для небольшого количества кнопок.

 SB> Программа представляет из себя автомат, ходящий по графу состояний.
 SB> Переходы инициируются нажатием одной из кнопок. Каждое состояние в общем
 SB> случае описывается указателями на другие состояния (по числу кнопок),
 SB> указателями на функцию входа в состояние, на функцию выхода из него и на
 SB> функцию отрисовки.

Красиво! И главное, корректность хорошо проверять. Достаточно нарисовать граф
и окинуть его взглядом на предмет недостижимых состояний или состояний, не
имеющих выхода. Спасибо за идею, побольше бы таких мессаг. А то все ругань не
по делу...

Hello, Serge Bryxin !
 >  IU> Лyчше бы поговоpили об алгоpитмах:)

 > Hе говори...

 >  IU>  У меня напpимеp катастpофически огpомный код полyчается пpи
 >  IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю.
 >  IU> Кто-то готов подсказать?

 > Я пару месяцев назад тут описывал один из очень красивых
 > вариантов. Во всяком случае - для небольшого количества кнопок.
 > Программа представляет из себя автомат, ходящий по графу
 > состояний. Переходы инициируются нажатием одной из кнопок. Каждое

А значения вводить как?

С уважением, Дима Орлов.

Dear Dima,

19 Jan 04 09:18, Dima Orlov wrote to Serge Bryxin:

 >> Программа представляет из себя автомат, ходящий по графу
 >> состояний. Переходы инициируются нажатием одной из кнопок. Каждое

 DO> А значения вводить как?

Так же.
Пусть (это достаточно стандартно) устанавливаемые цифры у нас перебираются
кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка Esc - выход. Тогда для
состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как переход на то же
самое состояние с функциями выхода из состояния, меняющими содержимое
соответствующих переменных. После повторного входа в состояние новые значения
автоматически отбразятся, об этом не надо думать. Кнопка Esc единственная
указывает на другое состояние.

Вот например, как будет описываться пункт меню входа в установку таймера, и
форма собственно установки:

mnu5:   .dw SetTime_init,form1 ; Ok: инициализировать состояние и перейти
        .dw empty_func,top_evt ; Esc: ничего не делать, выйти из меню
        .dw empty_func,mnu4    ; Up: на предыдущий пункт меню
        .dw empty_func,mnu6    ; Dn: на следующий пункт меню
        .dw draw_menu_string   ; ф-ция отрисовки (одна для всех пунктов меню)
        .db "Set Timer",0,0    ; доп.параметры для отрисовки (текст)
form1:  .dw SetTime_switch,form1 ; Ok: переключить ввод часов/минут
        .dw SetTime_save,mnu5    ; Esc: сохранить ввод и выйти обратно в меню
        .dw SetTime_minus,form1  ; Up: отнять единичку от значения
        .dw SetTime_plus,form1   ; Dn: прибавить
        .dw SetTime_draw         ; отрисовка часов и минут
                                 ; доп.параметры функции отрисовки не нужны

Может показаться, что количество мелких функциюшек переваливает все разумные
пределы. При бездумном подходе так и выйдет.
Hа самом деле оказывается (на практике), что значительная часть функций
невероятно похожи. И засчет правильной инициализации состояния (например,
считать нужное значение из EEPROM в специально предназначенную ячейку), можно
многие функции отрисовок и обработок унифицировать.

Инструмент невероятно гибок.
Hапример, в вышеприведенном тексте я слукавил (для читаемости). Т.е. я это
делаю не так. Если расписать функции, окажется, что
прибавление/вычитание/отрисовка каждый раз вынуждены проверять состояние ввода
часов/минут. А это долго и некрасиво.
Тогда я создал еще одну форму, аналогичную описанной. Кнопка Ok ходит между
формами туда-сюда. Функция SetTime_switch отсутствует (как и ячейка пямяти,
хрянящая это состояние). А функции в каждой из форм устанавливают и рисуют уже
конкретно то, что надо (т.е. действительно состоят из нескольких строк).
Прибавкой 18 байт к данным (именно столько занимает описание состояния) я
сэкономил порядка 50-80 байт кода (не говоря уж о читаемости сырца).

        Sincerely yours,
                         Old Greaser.

Hello, Serge!
You wrote to Dima Orlov on Tue, 20 Jan 2004 00:49:00 +0300:

 SB> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
 SB> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка
 SB> Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/Ok будут
 SB> отрабатываться как переход на то же самое состояние с функциями
 SB> выхода из состояния, меняющими содержимое соответствующих
 SB> переменных. После повторного входа в состояние новые значения
 SB> автоматически отбразятся, об этом не надо думать. Кнопка Esc
 SB> единственная указывает на другое состояние.

    Поскипано.
    Сергей, по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
_невероятно_ неудобно. Добраться до нужного места, установить нужные IP
адреса и корректно выйти обратно... жалко мне пользователей, я-то через
инженерную консоль всё это проделываю :-)).
    Далее. Описываемый тобой механизм сводится к спин-боксам двух типов - с
непосредственным числовым значением при установленных ограничениях (считаем
только от 0 до 59) и с косвенной выборкой (выбор перебором одной из
мнемоник). "Форма" сводится к комментарию (напомнить пользователю где и что
мы сейчас делаем) и описанию входящих в неё спинбоксов - какую ячейку памяти
они должны использовать; какие ограничения/где лежит массив мнемоник; ширины
полей. Т.е. множества функций для такой простой задачи писать не нужно.
    Всё значительно усложнится, если потребуется верификация [совместимости]
вводимых значений на лету и/или появятся связи между значениями, например,
при выборе в поле "Месяц" придётся менять границы для поля "Число" и,
возможно, корректировать его (сбрасывать с 31 до 30). Подобные проверки,
нерегулярности и взаимозависимости довольно тяжело вылавливаются и без
машины состояний, тут вопрос совсем не в механизме описания.

With best regards,
            Alexander Derazhne.

Hello, Serge Bryxin !

 >>> Программа представляет из себя автомат, ходящий по графу
 >>> состояний. Переходы инициируются нажатием одной из кнопок. Каждое

 >  DO> А значения вводить как?

 > Так же.
 > Пусть (это достаточно стандартно) устанавливаемые цифры у нас
 > перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
 > кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/

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



С уважением, Дима Орлов.

Hi Dima, hope you are having a nice day!


20 Янв 04, Dima Orlov wrote to Serge Bryxin:

 >> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
 >> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
 >> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/

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

Я делал такое. Идея похожая. При входе в процедуру ввода передается
константа-тип числа. Формат числа
описывается в структуре. Структуры собраны в массив, индексом собственно
является тип вводимого числа.

const rom struct num_type num_types[] = {
    {NUM_TYPE_DOUBLE,   -999.999,   9999.999,   1000,   1, 3},  //
NUM_TYPE_DBL43
    {NUM_TYPE_DOUBLE,   -99.9999,   999.9999,   10000,  1, 4},  //
NUM_TYPE_DBL34
    {NUM_TYPE_DOUBLE,   -99.9,      99.9,       10,     4, 1},  //
NUM_TYPE_DBL31
    {NUM_TYPE_UDOUBLE,  0.1000,     1.1000,     10000,  3, 4},  //
NUM_TYPE_DBL14U
    {NUM_TYPE_UDOUBLE,  0.000,      0.999,      1000,   4, 3},  //
NUM_TYPE_DBL13U
    {NUM_TYPE_UDOUBLE,  0.000,      9999.999,   1000,   1, 3},  //
NUM_TYPE_DBL43U
    {NUM_TYPE_UDOUBLE,  10.0,       100.0,      10,     4, 1},  //
NUM_TYPE_DBL31U
    {NUM_TYPE_UDOUBLE,  0.0,        100.0,      10,     4, 1},  //
NUM_TYPE_MANPWR
    {NUM_TYPE_WORD,     0,          9999,       1,      4, 0},  // NUM_TYPE_PWD
    {NUM_TYPE_WORD,     50,         60000,      0.02,   4, 0},  //
NUM_TYPE_PPRD
    {NUM_TYPE_BYTE,     0,          250,        0.2,    6, 1},  //
NUM_TYPE_DLY1
    {NUM_TYPE_BYTE,     25,         250,        0.2,    6, 1},  //
NUM_TYPE_DLY2
    {NUM_TYPE_BYTE,     5,          250,        0.2,    6, 1},  //
NUM_TYPE_RFRSH
    {NUM_TYPE_BYTE,     0,          20,         1,      6, 0}   //
NUM_TYPE_REGN
};

В структуре описывается число знаков в числе, число знаков после запятой, тип
возвращаемого значения (double, short, и
т.п.), допустимый диапазон значений. Мне не требовалось делать зависимость от
других значений, но это не сложно:
достаточно добавить в структуру укзатели на соответствующие границы

А это собственно декларация функции. Указатель передается нетипизированным, и
уже внутри функции приводится к нужному
типу. Через этот же указатель возвращается результат, код ошибки (status) -
возвращаемое значение.

unsigned char ioWriteNumber(void *arg, unsigned char type);

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

Dear Dima,

20 Jan 04 12:29, Dima Orlov wrote to Serge Bryxin:

 >> Пусть (это достаточно стандартно) устанавливаемые цифры у нас
 >> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами,
 >> кнопка Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/

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

Да. Я охотно верю, что есть задачи (интерфейсы), в которых эта идея для ввода
данных плохо подходит.

        Sincerely yours,
                         Old Greaser.

   Alexander, ты ещё здесь сидишь?


Среда Январь 21 2004 15:33, Alexander Derazhne wrote to Serge Bryxin:

 SB>> Структура графа вообще такого понятия не предполагает. Т.е. все в
 SB>> руках дизайнера интерфейса.
 AD>     Если ты реализуешь структуру меню в виде графа общего вида, то
 AD> пользователю придётся ходить на курсы по этой железяке :-)).

 Структура html текста с гиперссылками - граф общего вида.
Тем не менее им без особых проблем пользуются, не ходя
ни на какие курсы по конкретным документам или сайтам ;)




                                                   Георгий

Dear Alexander,

20 Jan 04 03:38, Alexander Derazhne wrote to Serge Bryxin:

 SB>> для состояния формы ввода кнопки Up/Dn/Ok будут отрабатываться как
 SB>> переход на то же самое состояние с функциями выхода из состояния,
 SB>> меняющими содержимое соответствующих переменных.

 AD> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
 AD> _невероятно_ неудобно. Добраться до нужного места, установить нужные
 AD> IP адреса и корректно выйти обратно... жалко мне пользователей

1) В предыдущем резговоре не было ни одной ссылки на уровневость меню.
Структура графа вообще такого понятия не предполагает. Т.е. все в руках
дизайнера интерфейса.
2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон несколько
лет назад, когда они почти все обладали однострочными фактически меню? Было
_неверотно_ неудобно? Я как-то переживал это дело... :-)
3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными кнопками
специально для ввода этого адреса? :-)

 AD> Далее. Описываемый тобой механизм сводится к спин-боксам двух типов -
 AD> с непосредственным числовым значением при установленных ограничениях
 AD> (считаем только от 0 до 59) и с косвенной выборкой (выбор перебором
 AD> одной из мнемоник).

Механизм к этому не сводится. К этому сводился приведенный частный пример
использования механизма.
Изрядная кастрированность интерфейса в данном случае обусловлена не
предложенной структурой данных, а малым количеством кнопок. Hо я сразу
предупредил, что она не годится (или годится с серьезными ограничениями) для
больших клавиатур.
Для большой клавиатуры я бы предложил event-driven интерфейс.

Да и в конце концов исходный вопрос звучал как удобная организация именно меню.
Здесь формы появились только в результате приведения идеи к наиболее общему
случаю. А для _только_ меню у меня в одном проекте было реализовано то же
самое, но проще:

menu1:  .dw menu11,empty  ; Ok - вход в cледующий уровень, ничего не делать
        .dw 0             ; Esc - выход из меню
        .dw menu2         ; Up - следующий пункт
        .dw menu3         ; Dn - предыдущий пункт (закольцовано)
        .db "Меню 1",0    ; текст
menu11: .dw 0,SetTime     ; выполнить SetTime и покинуть меню
        .dw menu1
        .dw menu12
        .dw menu13
        .db "Меню 1.1",0

 AD> Всё значительно усложнится, если потребуется верификация
 AD> [совместимости] вводимых значений на лету и/или появятся связи между
 AD> значениями

Да.

 AD> Подобные проверки, нерегулярности и взаимозависимости довольно
 AD> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в
 AD> механизме описания.

Да. Hо я приводил механизм описания.

Hello, Serge!
You wrote to Alexander Derazhne on Wed, 21 Jan 2004 12:16:00 +0300:

 AD>> по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре
 AD>> _невероятно_ неудобно. Добраться до нужного места, установить
 AD>> нужные
 AD>> IP адреса и корректно выйти обратно... жалко мне пользователей

 SB> 1) В предыдущем резговоре не было ни одной ссылки на уровневость
 SB> меню.
 SB> Структура графа вообще такого понятия не предполагает. Т.е. все в
 SB> руках дизайнера интерфейса.

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

 SB> 2) У тебя есть сотовый телефон? Или так: у тебя был сотовый телефон
 SB> несколько лет назад, когда они почти все обладали однострочными
 SB> фактически меню? Было _неверотно_ неудобно? Я как-то переживал это
 SB> дело... :-)

    Не знаю, мобилки у меня нет до сих пор и ничего, обхожусь как-то.

 SB> 3) А ты как предлагаешь реализовать ввод IP адреса? Отдельными
 SB> кнопками специально для ввода этого адреса? :-)

    Нет. Просто отдельные поля _формы_, каковой является IP-адрес
воспринимаются пользователем как единое целое, а не как пункты подменю. В
силу этого либо усложняется ввод каждой цифры, либо навигация становится
нерегулярной и запутанной (с точки зрения пользователя). В одноуровневом
меню старенького, погребённого под слоем книг :-)  видюшника с
четырёхкнопочным интерфейсом конфигурирования _все_ поля "располагались" на
одном уровне, т.е. навигация была непрперывной.

 AD>> Всё значительно усложнится, если потребуется верификация
 AD>> [совместимости] вводимых значений на лету и/или появятся связи
 AD>> между значениями

 SB> Да.

 AD>> Подобные проверки, нерегулярности и взаимозависимости довольно
 AD>> тяжело вылавливаются и без машины состояний, тут вопрос совсем не в
 AD>> механизме описания.

 SB> Да. Hо я приводил механизм описания.

    Тогда уже всё равно как описывать - функции верификации внесут куда
больше накладных расходов.

Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne

Hello Igor,


IU>  Лyчше бы поговоpили об алгоpитмах:)
IU>  У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании
IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?

Связанные списки. Что тут еще подсказывать.
Например

/* Структура одного пункта меню */
typedef struct SS_MENU_ITEM_S
{
    char                     * str;            /* Указатель на строку,
                                               содержашую название пункта меню */
    struct SS_MENU_ITEM_S const *submenu;         /* Указатель на подменю     */
    void                    (* cmd)(void * data); /* Указатель на задачу,
                                                  исполняющую этот пункт       */
    void                     * data;              /* Указатель на данные,
                                                     передаваемый
                                                     задаче команды  */
} SS_MENU_ITEM_T;


Далее объявление

SS_MENU_ITEM_T const Menu_ViewSubmenuTbl[] =
{
{ "Буфер"         , &Menu_SelectBufSubmenuTbl[0],   0, 0 },
{ "Настройки"     , 0,   &CmdViewAdjust,   0 },
{ "Неисправности" , 0,   &CmdViewErrors,   0 },
{ "Время и версии", 0,   &CmdViewVer     , 0 },
{ 0               , 0,   0, 0 }
};

Hi Maxim.

17 Jan 2004, 00:49, Maxim Polyanskiy writes to Dimmy Timchenko:

 DT> Да нет, имел я дело с pазными ассемблеpами... этот покpивее будет, чем
 DT> у 8080.  Хотя, конечно, мощнее.

 MP> Там классическая си-оpиентиpованная аpхитектуpа

Да ничего классического там нет, ассемблеp как с бодуна делался: "а вот сейчас
ещё такую фичу сбоку слюной пpиклеим". :)  Если уж это RISC - делайте
симметpичную аpхитектуpу и действительно огpаниченное число команд.  Хотя для
постpоения компилятоpа, действительно, возможностей побольше, чем в 51-м.



Dimmy.

17-Jan-04 11:05 Igor Ulanov wrote to Maxim Polyanskiy:

IU> Пpосто логика пpогpамиpования на АВРе здоpово отличается от 51, мне
IU> напpимеp, yчившемyся на 8080, z80, 8086 очень тяжело пеpестpоится. Hо
IU> можно
IU> пpедположить, что мне показалась бы столь же неyдобным набоp комманд 51,
IU> начни я с АВРа.
 После PDP11 меня несколько лет наизнанку выворачивало от MCS51.
А сейчас ничего, даже нравится, если больше 256+256 байт не надо :-)

IU>  Лyчше бы поговоpили об алгоpитмах:)
IU>  У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании
IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?
Смотря что тебе надо, в смысле организации меню.
Индикация, управление.

Массивы структур и движок для хождения по ним.
Для множества сходных (по размеру и принципу редактирования) -- опять
массив структур-описателей и второй движок, который вызывает
функцию редактирования элемента.

wbr,