Как писать на С++ при создание приложений под ARM, Примеры Опции

[Hellper]

Посоветуйте примеры использование С++ при создание программ под архитектуру ARM микроконтроллеров. Такие примеры, чтобы показывали удобство и силу использование ООП, и тянуло сразу садится, вникать и кодить.
спасибо
пс желательно под компилятор от keil-а или gcc

ПС извините за дублирование. неполадки связи.

[brag]

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

В связи с этим вопрос: не могли бы Вы привести примеры микроконтроллерных задач, в которых "объектно-ориентированный" подход даёт ощутимые преимущества?

пример - графический юзверь-интерфейс. я какраз щас задачку ставить буду, где сложный gui, все на том же cortex-m3, QT там не пойдет, прийдется писать свой, тут и применю с++, посему и залез в эти темку

[scifi]

пример - графический юзверь-интерфейс. я какраз щас задачку ставить буду, где сложный gui, все на том же cortex-m3, QT там не пойдет, прийдется писать свой, тут и применю с++, посему и залез в эти темку

При всём уважении, это голословное утверждение. Делал GUI (насколько сложный - тут мнения в любом случае разойдутся) именно "объектным" способом, никакой тяги к "полиморфизму" не ощутил.
Отсюда и вопрос. Хотелось бы с обоснованием, где именно полиморфизм реально помогает.

[dxp]

При всём уважении, это голословное утверждение. Делал GUI (насколько сложный - тут мнения в любом случае разойдутся) именно "объектным" способом, никакой тяги к "полиморфизму" не ощутил.
Отсюда и вопрос. Хотелось бы с обоснованием, где именно полиморфизм реально помогает.

Это вы зря - GUI, как раз, то место, где ООП рулит в полный рост. Не знаю, как у вас было организовано, но типовая схема такая: все объекты GUI являются членами иерархии классов, где в базовых классах объявляются методы (т.е. виртуальные функции), назначение которых выполнять действия, сходные по назначению, но разные по реализации. Например, у нас есть объекты: главное меню, выпадающее/всплывающее меню, пункт меню, графическая кнопка, строка состояния и т.п., а так же есть органы управления прибором - несколько кнопок или небольшая [плёночная] клавиатура. Нам нужно организовать управление всем ворохом графических объектов, но сделать это как-то единообразно. К примеру, нужно обрабатывать кнопку Right (перемещение вправо). Для этого мы в базовом классе иерархии объявляем виртуальную (если в самом базовом, то кошерно её объявлять чисто виртуальной - pure virtual) функцю void right(). И во всех производных классах, где это необходимо, эта функция переопределяется, чтобы получить для каждого класса своё поведение.

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

Так вот, код для реализации этого будет до безобразия прост:

Код

    TWidget *focus; // указатель на активный графический элемент (виджет)

   ...

    focus = ...;   //  focus присваивается адрес графического элемента - как правило это присваивание происходит
                      // внутри методов самих виджетов

   ...

    if( is_key_clicked(GUI::KEY_RIGHT)
    {
        focus->right();
    }

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

Таким образом, достаточно написать не очень обширный код, где будет просто организован вызов одной (!) функции на каждый орган управления. А всё разнообразие поведения графических объектов уже будет реализовываться уже путём определения самих этих объектов. При такой схеме есть чёткое разделение назначения действия от его реализации, можно без труда добавлять новые виджеты, можно без страха и геморроя менять поведение существующих. И работает это эффективно и безошибочно.

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

Это сильно похоже на аналогичный прием на С, когда заводится массив указателей на функции, но в данном случае есть удобство том, что объект-обработчик инкапсулирует в себе все необходимые сущности для работы. Кроме того, у объекта можно завести не один, а несколько методов, т.е. расширить это дело.

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

[scifi]

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

Другими словами, средства полиморфизма из Си++ могут быть оправданы там, где на Си нужно было бы вводить "поле типа" или массив указателей на функции.
Неудивительно, что у меня нет к этому тяги: в моих задачах это редко встречается :-)
Ещё раз, спасибо за развёрнутое объяснение.