Dimon456 писал(а):Так вот, уважаемые, высокоинтеллектуальные программисты
мне не очень понятен, и не совсем приятен ваш сарказм и вот это ёрничанье.
мне не понятно, что именно вас не устраивает, какие именно цели вы пытаетесь достичь, поэтому я, естественно, рассказываю о том, что у меня в голове, и подходит оно вам или нет, я не знаю и знать не могу. не подходит - пропускайте мимо ушей, в чем проблема? подходит - используйте, тоже нормально всё.
ваше высказывание
Dimon456 писал(а):фото прибора оказалось наиболее полезным, да же лучше чем скрипт линкера ARV
меня поставило в тупик: как фотка могла что-то продвинуть в ваших поисках?! лично я в фото увидел только
исключительно бедный ассортимент возможностей для интерфейса с пользователем, в моём представлении "меню" для того прибора -
это геморрой не столько для программиста, сколько муки адовы для пользователя, ведь никакого осмысленного текста или даже его подобия там вывести невозможно! бывали в моей практике варианты с таким бедным интерфейсом (например, "таймер меньше не бывает" или "термостат меньше не бывает"), и даже управление одной-единственной кнопкой (с меню!!!) было, но разве этот опыт о чем-то говорит?! разве что о том, что
универсальный интерфейс может быть только для
универсальной платформы, а для
специализированных платформ и интерфейс будет
специальным,
исключительным,
экзотическим и
неповторимым.
учиться на экзотических примерах, имхо,
нечему, потому что шанс попасть в ту же самую ситуацию, что и автор экзотического интерфейса, невелик, и навыки автора вряд ли кому приодятся. имхо, конечно.
что касается скрипта линкера, то это вовсе не панацея для меню. это вообще не факт, что для меню.
это - для программиста. попробую кратко описать суть, хоть это и не совсем в тему топика.
итак, вы задумали сделать нечто в программе, что состоит из однотипных структур, функций, данных и т.п. - не важно, чего именно. просто
в разных местах кода (
в разных файлах то есть) у вас есть необходимость использовать некие однотипные сущности. в качестве примера могу привести программные таймеры. пункты меню тоже
могут попадать в эту категорию. или, как в моём Digiscript-е, обработчики строковых последовательностей для интерпретатора команд.
как вы поступаете при традиционном подходе? описваете структуру этого самого повторяющегося элемента, заводите массив из таких структур... так же, да? и вот затем вопрос: поскольку
выгодно иметь статический вариант этих данных (для экономии ОЗУ, в первую очередь актуально для AVR и т.п. маленьких платформ), то и
инициализация этого массива должна выполняться статически, т.е. на этапе компиляции. как известно, в Си статическая инициализация массива делается в момент его описания, т.е. как-то так
- Код:
my_data_struct_t my_array[DATA_COUNT] = {
// и тут многократно повторенные инициализаторы наших-ваших данных
};
вроде все просто и понятно, но ведь ваши данные (см. условие) вам нужны В РАЗНЫХ местах кода! и по ходу пьесы может возникать ситуация, когда количество этих данных будет меняться - вам пришла в голову очередная идея и вы решили добавить парочку таких структур. что же получается?
описание статического массива может быть только в одном месте, а это неудобно, поскольку заранее неизвестно, сколько именно таких структур будет надо, и где они будут требоваться. начинается чехарда с включением заголовочных файлов, с корректировкой констант, с дополнением инициализатора массива... все это не сложно, но, имхо, очень муторно.
что же придумал я? зная, что линкер, согласно скрипту, располагает данные, принадлежащие к одной
секции памяти, последовательно (т.е. именно так, как они располагаются в массиве!), я сделал макрос, который просто помечает переданный ему идентификатор, как данные в определенной секции памяти. это позволяет мне при помощи этого макроса описывать и реализовывать нужные мне структуры в любых местах кода, не описывая явно массив из этих структур, но благодаря скрипту линкера, работать с этими данными, как с данными в массиве! то есть я добился "размазывания" статического инициализватора массива по разным точкам кода.
при этом нет нужды корректировать константу, определяющую размер массива, т.к. его размер всегда будет именно таким, сколько данных я опишу - никакого оверхеда! хотя, конечно, оверхед небольшой будет, поскольку обращение к моим данным потребует
небольших вычислений. но этот оверхед минимальный.
наиболее зримо удобство этого подхода вы могли видеть именно в проекте Digiscript: при помощи макроса CMD(x) вы могли описать
обработчик строки в любом месте любого файла, не задумываясь о том,
в каком именно месте осуществляется пребор и поиск подходящего обработчика! это совсем не улучшает программу технически, но заметно освобождает программиста от рутины. только и всего.
в частности, программные таймеры тоже весьма удобно так определять. где приспичило - описали структуру таймера, и готово, он будет тикать, и в нужный момент сработает. и лишь в обработчике прерывания от физичекого таймера вы пишите небольшой код, который перебирает элементы "виртуального" массива программных таймеров (виртуального - потому что он физически нигде не описан, а создан скриптом линкера) и обрабатывает его данные).
предполагаю, что и систему меню можно организовать подобным образом, хотя в случае связного списка пунктов сделать это будет непросто... но я над этим вообще не думал.
только скрипт линкера
вот вообще никак не связан с
визуальной частью меню! вот ни на грамм! это - самокат для программиста, просто быстрее ехать, чем идти! а что там куда выводится и насколько это удобно/красиво, самокат и знать не знает, и ничего изменить не может.
как-то так вот.
что касается второй части ваших идей
Dimon456 писал(а):я бы конечно не отказался от компьютерной программы для построение пунктов меню и их зависимости
то сделать это, естественно, можно, но это будет лишь поводом для очередного "фу, не решает мою проблему", потому как натыкать мышкой цепочку пунктов - это одно, а красиво отбразить их на семисегментном индикаторе при помощи одной западающей, постоянно мокнущей кнопки, нажимаемой слепым пьяным пользователем - это другое.
Demiurg писал(а):Вообще то я на даче
нашел себе оправдание
я вот тоже на даче