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

ARV · Сообщение **ARV** » Вт авг 20, 2019 15:46:25

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

именно это я и сообщил давеча

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

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

no comments

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

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

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

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

Реклама

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 · Сообщение **ARV** » Ср авг 21, 2019 06:54:11

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

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

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

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

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

da-nie

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

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

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

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

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

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

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

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

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

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

smalcom

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

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

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

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

ЕМНИП 20-й.

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

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

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

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

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

jcxz

[uquote="Trully",url="/forum/viewtopic.php?p=3686288#p3686288"]Спасибо за очень ценный совет. А вот скажите, на ассемблере для STM32 писать можно?

))[/uquote]
Можно конечно. Но трудоёмкость будет выше. Лучше на асме писать отдельные функции. Только там, где нужно.

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

Добавлено after 3 minutes 14 seconds:
[uquote="smalcom",url="/forum/viewtopic.php?p=3686307#p3686307"]Если хочется именно ассемблер для души - попробуй MIPS, Но, это субъективщина.[/uquote]
Категорически не согласен! Ассемблер для DSP c55xx - вот это "для души"!

Reflector

[uquote="smalcom",url="/forum/viewtopic.php?p=3686358#p3686358"]Посмотрите шаблоны GPIO Чижова. Внутренности - это просто... суть С++. Но вот использование этого всего превращается в красивый, оптимизированный и надёжный код.[/uquote]
Либа Чижова уже устарела, потому так и выглядит. Во-первых, уже давно есть вариативные шаблоны, во-вторых, метапрограммирование сейчас движется в сторону value-based подхода. На примере списка пинов это выглядит так:

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

static void toggle() { toggle_(ports_, pins_); }

template<typename... Ports, typename... Pins>
static void toggle_(TypeList<Ports...> ports, TypeList<Pins...> pins)
{
	if constexpr (!empty(ports))
	{
		static constexpr uint32_t gpio = decltype(head(ports))::type::gpio;
		static constexpr uint32_t pinsMask = getPinsMask<gpio>(pins);
		GpioT<gpio, pinsMask>::toggle();
		toggle_(pop_front(ports), pins);
	}
}

static constexpr auto pins_ = transformToPins(TypeList<Pins...>{});
static constexpr auto ports_ = getPortList(pins_);

По крайне мере это уже похоже на обычное программирование

ARV · Сообщение **ARV** » Ср авг 21, 2019 10:04:17

Reflector писал(а):По крайне мере это уже похоже на обычное программирование

как по мне, так это выглядит, как кошмар нерожденного.

что проще: {разобраться в либе Чисжова или освоить вариативные макросы} или тупо написать руками дрыганье битом? я все понимаю, но не понимаю, зачем простое делать "удобным"? за то время, что я потратил на попытки понять, что наваял Чижов, я бы мог 100500 раз расписать самые хитрые манипуляции группами битов. т.е. все эти шаблоны и лямбды (сцуко, так и не понял, нахрена они нужны и что это вообще за дрянь) не окупаются по мозговым затрам, имхо...

Reflector

[uquote="ARV",url="/forum/viewtopic.php?p=3686391#p3686391"]как по мне, так это выглядит, как кошмар нерожденного.[/uquote]
Тем не менее, этот код ближе к тому, что обычно пишут люди не обремененные нюансами метапрограммирования

И его можно пошагово отлаживать...

что проще: {разобраться в либе Чисжова или освоить вариативные макросы} или тупо написать руками дрыганье битом? я все понимаю, но не понимаю, зачем простое делать "удобным"? за то время, что я потратил на попытки понять, что наваял Чижов, я бы мог 100500 раз расписать самые хитрые манипуляции группами битов. т.е. все эти шаблоны и лямбды (сцуко, так и не понял, нахрена они нужны и что это вообще за дрянь) не окупаются по мозговым затрам, имхо...

Например, я у себя могу написать такое:

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

Lcd<RM68140, LcdOrient::Landscape, PB7, GpioB<0xFF00>, PB2, PB0, PB1, PB6, 0, 2, 0> lcd;
lcd.init();

А можно так:

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

using LcdData = PinList<PA12, PA11, PB2, PA9, PB3, PC1, PC2, PC3>;
Lcd<S6D1121, LcdOrient::LandscapeRev, PB7, LcdData, PB2, PB0, PB1, PB6, 1, 2, 1>;
lcd.init();

Другой контролер, другие пины данных, другие тайминги и ошибка компиляции, т.к. я специально продублировал PB2... При инициализации все эти 13 пинов объединяются в общий список, чтобы задать им режим сразу для всех, это может быть эффективнее, допустим, если все пины относятся к одном порту. При записи компилятор обнаружит последовательность пинов PA12/PA11/PA9, они хоть и не идут подряд, но все равно данные для них можно забрать за один заход, а если у нас Cortex-M3 и выше, то дополнительно будет обнаружена последовательность PC1/PC2/PC3, тут порядок обратный, потому будет добавлена одна инструкция реверса бит RBIT. И даже когда на стадии компиляции будет получен список регистров и необходимых констант все равно будут выполнены дополнительные проверки, вдруг вместо RMW можно просто писать целиков в регистр, его половинку или четвертинку... Это эффективно практически насколько возможно и все равно одни будут говорить, что вместе с универсализацией часть ресурсов тратится впустую, а другие, что получается слишком сложно

А потом эти другие идут и пишут скриптовый язык для управления светодиодами и прикручивают к нему пошаговый отладчик, естественно полагая, что их мозговые затраты полностью окупились

ПростоНуб

[uquote="da-nie",url="/forum/viewtopic.php?p=3686353#p3686353"]А что именно вы используете из stl?[/uquote]
Проблема не в том, что я использую. Проблема в том, что STL, являясь уже давно стандартной библиотекой C++, используется подавляющим большинством других библиотек, которые возникает желание использовать.

TC, опасайтесь советов smalcom. не подозревающего, что многие бибилиотеки С++ имеют собственные сборщики мусора (даже некоторые реализации STL). И не в курсе, что ряд библиотек С++ пользуются собственным управлением памятью, аллоцируя у системы только относительно крупные страницы памяти в свой пул. Иными словами, парадигма C++ библиотек, обычно, в повышении общего быстродействия ценой периодического увеличения времени выполнения одного и того же метода - читайте "увеличением времени реакции".

ARV, о вкусах не спорят, кто-то "кубами" ногодрыгом занимается, а кто-то LD или FBD/SFC предпочитает. А мне удобней ногодрыгом заниматься средствами С препроцессора.
Что касается библиотеки Чижова, то, например, работа с SPI там реализована неудобно - нет асинхронного вывода. На МК часто нет возможности иметь в памяти буфер для того же TFT дисплея. А значит, вместо ожидания окончания передачи очередного байта, логично кодировать следующий байт или байты.

Reflector

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3686452#p3686452"]Что касается библиотеки Чижова, то, например, работа с SPI там реализована неудобно - нет асинхронного вывода. На МК часто нет возможности иметь в памяти буфер для того же TFT дисплея. А значит, вместо ожидания окончания передачи очередного байта, логично кодировать следующий байт или байты.[/uquote]
Это проблема разве что для AVR, на более продвинутых мк можно переключится на 16-ти битную передачу и обычно там есть FIFO, потому асинхронный вывод особо не нужен.

ПростоНуб

Reflector, во-первых, скольки битная не была бы передача, но если нет асинхронного вывода - она проблемы не решает. Ведь метод будет ждать окончания передачи, вместо того, чтобы вернуть управление вызывающей программе для вычисления последующих байтов.
Во-вторых, не только для AVR. Тот же STM32F FIFO для SPI не имеет.
В-третьих, для того же STM32F103 асинхронный вывод в SPI у Чижова реализован, хоть и криво, с риском потери принимаемых данных. То бишь, либо асинхронный вывод без чтения, либо синхронный ввод-ввод.

ARV · Сообщение **ARV** » Ср авг 21, 2019 12:20:57

Reflector писал(а):А потом эти другие идут и пишут скриптовый язык для управления светодиодами и прикручивают к нему пошаговый отладчик, естественно полагая, что их мозговые затраты полностью окупились

да вы, батенька, оказывается, злой!

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

Reflector писал(а):и все равно одни будут говорить, что вместе с универсализацией часть ресурсов тратится впустую, а другие, что получается слишком сложно

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