Jump to content

    

C++ и ООП для микроконтроллеров AVR

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
и программировать на нем конечно можно, но по моему убеждениею неэффективно и громоздко.

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Код был идеально красиво написан, со всеми отступами и пояснениями. Но понять что там наверчено удалось с 18й попытки. Такого иезуитского подхода я прежде не видел,

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

Edited by tAmega

Share this post


Link to post
Share on other sites
нашел единственное объяснение, для чего там был использован C++, это идеальный способ существенно запутать все что можно запутать.

 

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

main(O,_){for(_?--O,main(O+2,"?DKwhQH?b@`JD|?dA@TIT?qpEzR?hB@hTB?BHB@hTB"
"?Po@SdB?"[O]):5;O&&_>1;printf("%s",_-'?'?_&1?"||":" ":(_=0,"\n")),_/=2);}

Share this post


Link to post
Share on other sites

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

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

А это значит, что все объекты создаются заранее.

А в системе где все заранее определено я бы использовал ООП исключительно из-за личных пристрастий (к примеру, нравится так абстрагироваться).

 

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

Ембеддерская программа принципиально не должна содержать эксепшены.

 

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

Share this post


Link to post
Share on other sites
Программирование в ООП обычно требует динамического выделения памяти.

...

Я, лично, сишному менеджеру кучи не доверяю и никогда не использую.

...

Ембеддерская программа принципиально не должна содержать эксепшены.

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Никакого отношения динамическое выделение памяти к ООП не имеет.

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

Share this post


Link to post
Share on other sites
Дык если взять STL

 

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

 

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

Share this post


Link to post
Share on other sites
 С++ это скорее "Си с классами".

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

Share this post


Link to post
Share on other sites

Об ООП хорошо думаю :), но в AVR ООП тесно.

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

 

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

Share this post


Link to post
Share on other sites

ОП имеет смысл когда есть что наследовать и есть кому.

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

А следовательно, физического смысла не имеют.

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
ОП имеет смысл когда есть что наследовать и есть кому.

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

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

А следовательно, физического смысла не имеют.

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

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

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
Вообще, как Вы можете говорить после этого о достатках и недостатках ООП?

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this