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

[Hellper]

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

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

[gladov]

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

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

С++ плохо подходит для ARM. Серьезно! Появляются накладняки на требуемую память, ООП пытается тянуть за собой в проект использование динамической памяти и еще много всяких неудобств. Зачем это Вам?

А если серьезно, то я сам пишу под АРМ на С++, но чтобы к этому прийти, надо сначала понять что такое ООП вообще, зачем оно нужно, почему иногда оно удобнее, и лишь потом, если придет просветление (для ускорения процесса можно почитать, например, про шаблоны ООП) можно пытаться прикрутить объекты к АРМам.

[dxp]

С++ плохо подходит для ARM. Серьезно! Появляются накладняки на требуемую память, ООП пытается тянуть за собой в проект использование динамической памяти и еще много всяких неудобств. Зачем это Вам?

А если серьезно, то я сам пишу под АРМ на С++, но чтобы к этому прийти, надо сначала понять что такое ООП вообще, зачем оно нужно, почему иногда оно удобнее, и лишь потом, если придет просветление (для ускорения процесса можно почитать, например, про шаблоны ООП) можно пытаться прикрутить объекты к АРМам.

Два, нет - три вопроса:

1. Какое отношение имеет ООП к динамической памяти?
2. Почему вы ставите знак равенства между С++ и ООП?
3. Причём тут вообще паттерны проектирования? Какое они имеют отношение к ЯП С++?

[gladov]

Два, нет - три вопроса:

1. Какое отношение имеет ООП к динамической памяти?
2. Почему вы ставите знак равенства между С++ и ООП?
3. Причём тут вообще паттерны проектирования? Какое они имеют отношение к ЯП С++?

Начну со второго: да, возможно я излишне строго приравнял C++ и ООП. Это конечно не так, я немного не то имел ввиду. Конечно, C++ дает нам много вкусностей помимо "классического" ООП. Но, согласитесь, основные достоинства языка С++ заключаются в его возможности писать ОО-код. Именно поэтому я не приравнял С++ и ООП, но поставил их совсем рядом и позволил себе в первом посте сместить акцент в сторону ООП.
Отношение ООП к динамике? Да никакого! Но во многих учебниках, а также в ВУЗах, преподается ООП (позвольте я все же буду тут писать про ООП, коль уж мой первый пост был де-факто про него) в тесной свзяке с динамической памятью, ибо так легче показать виртуализацию и полиморфизм. Поэтому и написал, что "ООП пытается тянуть за собой ....". Согласитесь, многие вещи удобнее реализовываются если использовать динамику? Однако этого лучше не делать, либо делать с умом, понимая механизмы и возможные последствия.
Паттерны? А разве плохо знать о них? А к С++ они имеют прямое отношение: их можно реализовать используя С++, а вот на С сделать то же самое гораздо сложнее.

[dxp]

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

Начну со второго: да, возможно я излишне строго приравнял C++ и ООП. Это конечно не так, я немного не то имел ввиду. Конечно, C++ дает нам много вкусностей помимо "классического" ООП. Но, согласитесь, основные достоинства языка С++ заключаются в его возможности писать ОО-код. Именно поэтому я не приравнял С++ и ООП, но поставил их совсем рядом и позволил себе в первом посте сместить акцент в сторону ООП.

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

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

1. Процедурую, когда программист разбивает код на функции (процедуры) и строит программу как совокупность вызовов процедур (точно как в традиционном С).
2. Объектную, когда программист размещает код в компактных объектах, скрывая детали реализации с помощью инкапсуляции и абстракции и определяя интерфейс для взаимодействия объектов с внешним (для объекта) миром, а программу, строит определяя взаимодействия объектов между собой и с другими программными сущностями.
3. Объектно-ориентированную, когда код строится в виде иерархий полиморфных классов (см выше).

Каждая парадигма имеет свои сильные и слабые стороны, и применять их все три надо к месту. С++ все эти три парадигмы поддерживает одинаково хорошо. И ни одна из них не порождает сколько-нибудь заметных накладных расходов в программе, чтобы их нельзя было использовать даже на 8-битных малышах, не говоря уже об АРМах. Где уместен С, там уместен и С++.

Отношение ООП к динамике? Да никакого! Но во многих учебниках, а также в ВУЗах, преподается ООП (позвольте я все же буду тут писать про ООП, коль уж мой первый пост был де-факто про него) в тесной свзяке с динамической памятью, ибо так легче показать виртуализацию и полиморфизм.

Совершенно нет. Никакого абсолютно отношения виртуальные функции и полиморфизм не имеют к работе со свободной памятью. Это полностью ортогональные вещи. Механизм виртуальных функций в С++ строится на таблицах указателей на функции - это вполне обычный механизм, хорошо известный ещё из языка С. Разница в том, что в С эти таблицы создавать, инициализировать адресами функций приходится вручную, в С++ этим занимается компилятор. Когда вы пишете код с таблицами указателей на функции на С, вам же не приходит в голову их размещать, в обязательном порядке вызывая malloc() - эти таблицы вполне нормально живут в статической памяти (да хоть в стеке, если время жизни таблицы достаточно для обслуживания кода, её использующего).

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

Поэтому и написал, что "ООП пытается тянуть за собой ....". Согласитесь, многие вещи удобнее реализовываются если использовать динамику?

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

В программах для РС, где присутствует GUI, это обычная практика - создавать объекты с помощью оператора new, т.к. GUI сам по себе динамичен - окна появляются и закрываются, действия пользователя на этапе написания программы не известны. Учитывая, что операция создания объекта в свободной памяти на РС не очень дорогая, этот подход широко применяется там и для других потребностей. Но и там злоупотреблять этим ни к чему. И недаром тов. Александреску даже разработал специальный быстрый менеджер памяти для использования его с небольшими объектами (он подробно описан в его книжке "Modern C++ design").

Паттерны? А разве плохо знать о них? А к С++ они имеют прямое отношение: их можно реализовать используя С++, а вот на С сделать то же самое гораздо сложнее.

Знать о них не плохо. Только это, вообще-то, приёмы проектирования, и реализовываться они могут на многих языках, а не только на С++. И уж нет никаких особы предпосылок к тому, чтобы считать их непригодными для реализации в embedded системах, в частности на ARM. Например, паттерн Singleton очень хорошо реализуется не то, что на ARM, но даже на AVR, и мы давно и широко его применяем.