Вопросы по С/С++ (СИ)

[Trully]

То есть как я и предполагал - востребовано в основном в RTOS или при динамическом выделении памяти. Потому что в стеке переменные оказываются недействительными при выходе из функции. Указатель стека перемещается назад по памяти. Здесь я имею ввиду ядро ARM в STM32. Изначально меня интересовал вопрос именно в применении STM32.

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3686057#p3686057"]ну я не знаю, что еще в программировании, кроме памяти, можно освобождать [/uquote]
Любые занятые ресурсы: порты ввода/вывода, другие периферийные блоки, TCP-сокеты, семафоры и т.п.

[ARV]

порты ввода/вывода, другие периферийные блоки, семафоры и т.п.

это все "память"

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3686072#p3686072"]это все "память" [/uquote]
Ну да, ещё скажите - это всё транзисторы. А значит - деструктор должен освобождать транзисторы

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3686072#p3686072"]

порты ввода/вывода, другие периферийные блоки, семафоры и т.п.

это все "память" [/uquote]
Ну, например, остановить таймер, выключить постоянные преобразования АЦП или даже перевести пин из режима вывода в режим ввода - это энергосбережение, а не память. И все эти операции вполне могут возлагаться на деструктор объекта.

[ARV]

Он только разрушает объект.

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

[Reflector]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3686061#p3686061"]Для МК с ограниченным объемом памяти я предпочитаю C, а не C++. Потому как C++ без STL большого смысла не имеет, а с STL - в такие МК все равно не лезет.[/uquote]
В С STL нет, все пишут сами, значит и на С++ можно написать, только оно будет более универсальное, простое в использовании, а при умелом обращении еще и более эффективное.

[ПростоНуб]

ARV, по Вашей логике можно было ограничиться только вторым пунктом, так как освобождение памяти тоже является "предсмертным действием". Вот только польза от такого описания деструктора сомнительна. Люди лучше понимают предназначение чего-либо на практических примерах, чем на совершенно правильных, теоретических обобщениях )

Добавлено after 2 minutes 12 seconds:
Reflector, проблема в том, что чем универсальней что-либо - тем больше ресурсов оно потребляет без всякого толку. На ПК я так вообще STL почти не пользуюсь - QT хватает )

[ARV]

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

именно это я и сообщил давеча но освобождение памяти выделил с целью пояснить топикстартеру, какую именно память деструктор должен освободить.

Люди лучше понимают предназначение чего-либо на практических примерах, чем на совершенно правильных, теоретических обобщениях

no comments если мьютекс или семафор более понятны начинающему, чем то, что написал я, то я пас.

Добавлено after 4 minutes 34 seconds:

Потому что в стеке переменные оказываются недействительными при выходе из функции.

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

[Trully]

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

С работой деструктора тоже немного разобрался. И на данном этапе применение деструктора я вижу например в деинициализации какого либо периферийного модуля после выполнения какого то разового действия. То есть не обязательно чисто по книжному - освобождение памяти - а чисто практически. Возможно я не прав на данном этапе освоения но я просто ищу практическое применение.
Динамическое выделение памяти и работу в RTOS на данном этапе я не рассматриваю. Я достаточно хорошо знаком с работой этих вещей на простом Си поэтому для меня не секрет как это работает. Сейчас меня интересуют базовые навыки на С++

[da-nie]

Почему это?
Для embedded я бы наоборот рекомендовал - никогда не создавать объектов через new.

Потому что исходное утверждение относилось к динамическому созданию объектов. И создавать предлагалось malloc.

То есть как я и предполагал - востребовано в основном в RTOS или при динамическом выделении памяти.

Нет. Востребовано это везде, где есть захват какого-либо ресурса. Ах да, советую ещё RAII использовать - очень красивая штука.

Потому как C++ без STL большого смысла не имеет,

Вообще-то, имеет. stl - это по желанию. Универсальность там есть, но за это придётся заплатить либо памятью, либо скоростью, либо нечитаемостью кода.

что просто так созданные "локальные" объекты после выхода из функции не исчезают...

Не исчезают только созданные в куче. А все остальные, как обычные переменные.

[ПростоНуб]

da-nie, лично для себя я не нашел преимуществ в использовании С++ без STL и огромном количестве наработок, на нем основанных. А раз все равно почти ни одной кросс-платформенной библиотеки С++ использовать невозможно, то проще ограничиться C. Там то любая платформо-независимая библиотека заработает )

[Trully]

[uquote="da-nie",url="/forum/viewtopic.php?p=3686145#p3686145"]RAII использовать .[/uquote]
Согласен! Я про это в принципе уже и предположил. Только не знал что именно так оное называется

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

[jcxz]

[uquote="Trully",url="/forum/viewtopic.php?p=3686170#p3686170"]И еще вопрос такой. Скорее идеологического плана. Как вы думаете. Насколько оправдано использование С++ именно в эмбедде, в микроконтроллерах?[/uquote]
В ембеде главное чтобы девайс работал. Без глюков и зависаний. Чтобы байты в порты правильно слались и лампочки мигали как надо. Чтобы ресурсов потратить по-минимуму, а результата получить по-максимуму.
Это - Главное. А на чём оно будет реализовано - дело десятое.

[Trully]

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

[smalcom]

[uquote="Trully",url="/forum/viewtopic.php?p=3686288#p3686288"]А вот скажите, на ассемблере для STM32 писать можно?[/uquote]
Можно, но не нужно. )) Серьёзно - можно, но АРМовский ассемблер не очень приятен на вид. Если хочется именно ассемблер для души - попробуй MIPS, Но, это субъективщина.

[uquote="Trully",url="/forum/viewtopic.php?p=3686288#p3686288"]Выходит что С++ - фигня и профанация? Или всетаки нет?[/uquote]
Половина интернета этим забита. Выучите для начала С++, а потом пробуйте его на МК. Для веселья покажу достоинство и недостаток С++ в одном флаконе:

Код: Выделить всё

А = 2;
Б = 3;

cout << А + Б << endl;

Что будет выведено на экран? ))

[ПростоНуб]

Trully, С++ позволяет создавать такие иерархии классов, что программирование с их использованием становится существенно проще и надежней, чем на C. Поэтому в случаях, когда подобная иерархия востребована (например - сложный графический пользовательский интерфейс) - С++ заметно выигрывает у С по трудоемкости и надежности. Однако, быстродействие программы на C++ (я говорю именно о C++, а не о "С с классами и шаблонами") всегда будет ниже и, самое главное, менее предсказуемо, чем программы на C. Например, в самый непоходящий момент может включится сборщик мусора, аллоцирование памяти, какой-то обработчик исключения и т.п. Особый кайф доставляет, когда это случается в обработчике прерывания. Например, использование в прерывании методов std::vector.insert() или erase() заманчиво, но не рекомендуется. Если же быстродействия МК и памяти хватает с лихвой во всех предполагаемых ситуациях, то использование C++ вполне оправдано.

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

[ARV]

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

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

если вам важно быть на гребне волны - С++ 18-й версии (или это уже не пик?), со всеми их лямбдами (кто бы объяснил, что это...) и прочими наворотами.

если вам важно быстро и легко решать свои программы - лучше Си пока не придумано.

ассемблер? главнейший минус - жесткая привязка к архитектуре, т.е. невероятная трудоемкость переписывания уже реализованного алгоритма для новой платформы. если вас это не пугает - можно и на ассемблере.

[da-nie]

da-nie, лично для себя я не нашел преимуществ в использовании С++ без STL и огромном количестве наработок, на нем основанных.

А что именно вы используете из stl?

Насколько оправдано использование С++ именно в эмбедде, в микроконтроллерах? Вот реально.

В случае проектов со сложной логикой - абсолютно оправдано и даже необходимо. Переписывать же с С на С++ просто так вряд ли имеет смысл.

В ембеде главное чтобы девайс работал.

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

Выходит что С++ - фигня и профанация? Или всетаки нет?

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

со всеми их лямбдами (кто бы объяснил, что это...)

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

[smalcom]

С++ заметно выигрывает у С по трудоемкости и надежности. Однако, быстродействие программы

Например, в самый непоходящий момент может включится сборщик мусора, аллоцирование памяти

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

С++ 18-й версии (или это уже не пик?)

ЕМНИП 20-й.

со всеми их лямбдами (кто бы объяснил, что это...)

С++ переусложнён - факт. Я эти штуки использую как функции в функции - очень полезная штука и код красивее становится.

если вам важно быстро и легко решать свои программы - лучше Си пока не придумано.

Посмотрите шаблоны GPIO Чижова. Внутренности - это просто... суть С++. Но вот использование этого всего превращается в красивый, оптимизированный и надёжный код.

ПС. Для AVR и STM32 есть ещё окружения на Rust и Ада. Попробуйте, может понравится.