Здравствуйте!

Что вы думаете по поводу ООП для микроконтроллеров AVR на языке C++?

Благодарю заранее!

Нравиться пишите на С++ для AVR.

Смотря какой AVR, если 8 битные модели, то ООП это роскошь, и программировать на нем конечно можно, но по моему убеждениею неэффективно и громоздко.

Понимаете ли, многие не видят разницы между ООП, C++, STL и т.д. Конечно, темплейт типа vector уложит бедный AVR в могилу тут же. Некоторые фичи ООП имеет смысл применять для упрощения писанины - наглядный пример - устройство критической секции в ScmRTOS (хотя, лично мне больше нравится цикл for).

Часто полезна перегрузка операций - опять же, для уменьшения писанины.

Полновесная работа с объектами обычно упирается в ограниченность ресурсов. Хотя, есть любители, которые пользуют это дело во всю.

Видел код на C++ для AVR, нашел единственное объяснение, для чего там был использован C++, это идеальный способ существенно запутать все что можно запутать.
Код был идеально красиво написан, со всеми отступами и пояснениями. Но понять что там наверчено удалось с 18й попытки. Такого иезуитского подхода я прежде не видел,
но взял на заметку, как именно надо путать следы, чтобы стать незаменимым для сопровождения данной конкретной программы.

Сообщение отредактировал tAmega - May 10 2009, 09:02

Думаете на Plain C нельзя запутать?

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

Я, лично, сишному менеджеру кучи не доверяю и никогда не использую. Неужели я могу доверять механизмам ООП, которые скрыты еще сильнее?
Ембеддерская программа принципиально не должна содержать эксепшены.

Но я человек, который использует Си, как более удобный ассемблер (порок воспитания). Возможно, реальность - другая.

Во-во. Смешались в кучу кони, люди... То, о чем я говорил.

Никакого отношения динамическое выделение памяти к ООП не имеет.

Нет такого понятия - "сишный менеджер кучи". Может быть - менеджер кучи в составе библиотек, поставляемых с каким-либо компилятором.

Эксепшены - это такая удобная форма goto. Или, даже longjmp, если быть точным.

Дык если взять STL, то там куда не плюнь, везде динамическое выделение памяти, а без STL, С++ это скорее "Си с классами".

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

Хотя, болтают всякое про то, что STL - составная часть C++... Но то дураки болтают

А ,пардон, этого мало для эмбеда?

Об ООП хорошо думаю , но в AVR ООП тесно.
Какая необходимость использовать ООП в AVR, когда есть С?

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

А городить ООП только из-за перегрузки функций, имхо - лишнее. Писанины все-таки больше.

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

А так, конечно, очень удобно, что в структуру можно нормальным и явным образом добавлять функции. Безусловно. Иногда очень удобно.

К счастью, такие ситуации возникаю довольно часто. К счастью, потому что это не даст погубить ООП.

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

Наверно писанины будет меньше, если городить нечто подобное на Plain C.

Без комментариев.

Это тоже без комментариев.


Вообще, как Вы можете говорить после этого о достатках и недостатках ООП?

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

Каждый должен выбрать себе собственный способ полоскания мозгов, и не стоит в этом людям мешать