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

[Hellper]

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

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

[andrewlekar]

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

[dxp]

(наследование от интерфейса и поточная обработка), то тут же вся система станет крайне неустойчивой.

Почему? В чём причины неустойчивости?

Конкретно: множественное наследование сразу ставит крест на проекте,

Поясните? И причём тут множественное наследование? О нём вообще ни слова не было сказано.

перегрузка функций и операторов приводит к очень хитрым багам,

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

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

А голова-то на что? Средства-то надо применять осмысленно и к месту, а не ради них самих, о чём было сказано выше.

Использование паттернов не имеет отношения к С++, но в микроконтроллерах не имеет особого смысла. Куда можно в AVR засунуть синглтон?!

Да как обычно - чтобы избавиться от зависимости порядка создания объектов при раздельной компиляции файлов проекта. Затраты на него копеечные.

Использование шаблонов С++ сильно тормозит компиляцию

Да, несколько секунд лишних, обычно, приходится потратить.

и плохо контролируется по расходу памяти.

Это только если использовать бездумно и не представлять себе, во что выливается та или иная языковая конструкция. На сях тоже можно начать бездумно маллоки метать направо и налево, и будет "плохо контролируемый расход памяти".

В общем, это неправда, что С++ оправдан везде, где оправдан С.

Технически с точки зрения эффективности везде. А то, что голову надо включать, так это универсальное правило для любого ЯП. Единственное, с чем соглашусь, что С++ требует больше времени на изучение в силу много большего разнообразия и сложности самого языка. Это его единственный объективный недостаток перед С.

[andrewlekar]

Поясните? И причём тут множественное наследование? О нём вообще ни слова не было сказано.

С++ позволяет множественное наследование, вот и упомянул. Просто перечисление объективных недостатков языка.

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

Адресная арифметика - это также и чисто микроконтроллерная область. И хоть вы на чём пишите, залезать в неё придётся. А неаккуратная работа с памятью более вероятна как раз в С++, потому что там куда чаще встречается динамическое размещение объектов.

Да как обычно - чтобы избавиться от зависимости порядка создания объектов при раздельной компиляции файлов проекта. Затраты на него копеечные.

Ага, сначала создавать себе проблемы, используя С++, а потом мужественно их решать

А то, что голову надо включать, так это универсальное правило для любого ЯП.

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

[Danis]

А неаккуратная работа с памятью более вероятна как раз в С++, потому что там куда чаще встречается динамическое размещение объектов.

Набрался терпения и решил немного поработать писателем и корректором. Да, действительно адресная арифметика и динамическое размещение памяти при неопытности «да и опытности» тянет за собой источники потенциальных ошибок. Microsof, например, для решения этой проблемы и не только, разработал платформу .NET, под которую можно писать приложения на многих языках программирования, в частности применять C++ с расширением управляемости. (С++.Net). Код здесь, выполняется под управлением обще языковой среды выполнения CLR (Common Language Runtime), называется «управляемым кодом». Программы состоят из кода и данных, и обще языковая среда выполнения CLR обеспечивает поддержку и управляемым данным, и управляемому коду. Управляемые данные размещаются в управляемой динамически распределяемой области памяти (куче), которая имеет весьма ценную особенность — автоматическую сборку мусора (garbage collection). Если при создании программ на обычном C++ программист должен сам создавать средства управления динамически распределяемой областью памяти, то обще языковая среда выполнения CLR реализует этот процесс, отслеживая ссылки на объекты и автоматически освобождая ресурсы, занятые объектами, которые стали недоступны программе. Фактически, управляемые и неуправляемые (к которому мы все так привыкли) код и данные на C++ могут быть определены в одном и том же исходном файле, и в некоторой степени эти два мира могут взаимодействовать. Хотя использование управляемого кода и данных имеет много преимуществ (пример выход за пределы массива, на этапе run-time сразу выбросит исключение) оно может привести к снижению производительности и потере гибкости. Поэтому во многих случаях неуправляемый C++, при опытности и знаниях, оказывается лучшим выбором для создания программ.