Вопрос
У меня есть два компилятора на моем оборудовании C ++ и C89
Я думаю об использовании C ++ с классами, но без полиморфизма (чтобы избежать vtables). Основные причины, по которым я хотел бы использовать C ++:
- Я предпочитаю использовать «встроенные» функции вместо макроопределений.
- Я хотел бы использовать пространства имен, поскольку префиксы загромождают код.
- Я считаю, что C ++ более безопасен в основном из-за шаблонов и подробного приведения типов.
- Мне очень нравятся перегруженные функции и конструкторы (используемые для автоматического приведения).
Видите ли вы какие-либо причины придерживаться C89 при разработке для очень ограниченного оборудования (4 КБ ОЗУ)?
Заключение
Спасибо за ответы, они действительно помогли!
Я продумал эту тему и остановлюсь на C главным образом потому, что:
- Фактический код на C легче предсказать, и это действительно важно, если у вас всего 4 КБ оперативной памяти.
- Моя команда состоит в основном из разработчиков C, поэтому расширенные функции C ++ будут использоваться нечасто.
- Я нашел способ встроить функции в свой компилятор C (C89).
Трудно принять один ответ, поскольку вы дали очень много хороших ответов. К сожалению, я не могу создать вики и принять ее, поэтому выберу один ответ, который заставил меня задуматься больше всего.
Ответы:
Две причины использовать C вместо C ++:
Кроме того, в исходном вопросе и ряде комментариев упоминается 4 КБ ОЗУ . Для типичного встроенного процессора объем ОЗУ (в основном) не связан с размером кода, поскольку код хранится и запускается из флэш-памяти.
Конечно, необходимо иметь в виду объем места для хранения кода, но по мере появления на рынке новых, более емких процессоров это меньшая проблема, чем раньше, для всех проектов, кроме наиболее чувствительных к стоимости.
Об использовании подмножества C ++ для использования со встроенными системами: теперь существует стандарт MISRA C ++ , на который, возможно, стоит обратить внимание.
РЕДАКТИРОВАТЬ: См. Также этот вопрос , который привел к спору о сравнении C и C ++ для встроенных систем.
источник
Для цели с очень ограниченными ресурсами, такой как 4 КБ ОЗУ, я бы проверил воду с некоторыми образцами, прежде чем приложить много усилий, которые не могут быть легко перенесены обратно в чистую реализацию ANSI C.
Рабочая группа по встроенному C ++ действительно предложила стандартное подмножество языка и стандартное подмножество стандартной библиотеки для его использования. Я потерял след этих усилий, когда, к сожалению, умер журнал пользователя C. Похоже, в Википедии есть статья , а комитет все еще существует.
Во встраиваемой среде вам действительно нужно быть осторожным с распределением памяти. Чтобы усилить эту заботу, вам может потребоваться определить глобал
operator new()
и его друзей для чего-то, что даже не может быть связано, чтобы вы знали, что это не используется. Сnew
другой стороны, размещение, вероятно, будет вашим другом при разумном использовании вместе со стабильной, поточно-ориентированной схемой распределения с гарантированной задержкой.Встроенные функции не вызовут особых проблем, если они не достаточно велики, чтобы быть настоящими функциями. Конечно, у замененных ими макросов была та же проблема.
Шаблоны тоже могут не вызвать проблемы, если их создание не выйдет из-под контроля. Для любого используемого вами шаблона проверьте сгенерированный код (карта ссылок может содержать достаточно подсказок), чтобы убедиться, что выполнялись только экземпляры, которые вы намеревались использовать.
Еще одна проблема, которая может возникнуть, - это совместимость с вашим отладчиком. Нет ничего необычного в том, что аппаратный отладчик, который можно использовать в других случаях, имеет очень ограниченную поддержку взаимодействия с исходным исходным кодом. Если вы действительно должны отлаживать сборку, то интересное изменение имен C ++ может добавить дополнительную путаницу в задачу.
RTTI, динамическое приведение типов, множественное наследование, тяжелый полиморфизм и исключения - все это требует определенных затрат времени выполнения для их использования. Некоторые из этих функций стоят на уровне всей программы, если они используются, другие просто увеличивают вес классов, которые в них нуждаются. Знайте разницу и с умом выбирайте расширенные функции, зная хотя бы беглый анализ затрат и выгод.
В небольшой встроенной среде вы будете либо напрямую связываться с ядром реального времени, либо работать непосредственно на оборудовании. В любом случае вам нужно будет убедиться, что ваш код запуска среды выполнения правильно обрабатывает конкретные задачи запуска C ++. Это может быть так же просто, как убедиться, что вы используете правильные параметры компоновщика, но поскольку обычно есть прямой контроль над источником для точки входа при сбросе при включении питания, вам может потребоваться аудит, чтобы убедиться, что он все делает. Например, на платформе ColdFire, над которой я работал, инструменты разработчика поставлялись с модулем CRT0.S, в котором присутствовали инициализаторы C ++, но были комментарии. Если бы я использовал его прямо из коробки, я был бы озадачен глобальными объектами, конструкторы которых вообще никогда не запускались.
Кроме того, во встраиваемой среде часто бывает необходимо инициализировать аппаратные устройства перед их использованием, а если нет ОС и загрузчика, то это делает ваш код. Вам нужно помнить, что конструкторы для глобальных объектов запускаются перед
main()
вызовом, поэтому вам нужно будет изменить локальный CRT0.S (или его эквивалент), чтобы инициализация этого оборудования была выполнена до вызова самих глобальных конструкторов. Очевидно, чтоmain()
уже слишком поздно.источник
Нет. Любые функции языка C ++, которые могут вызвать проблемы (полиморфизм времени выполнения, RTTI и т. Д.), Можно избежать при разработке встраиваемых систем. Существует сообщество разработчиков встроенных C ++ (я помню, как читал статьи о встроенных разработчиках, использующих C ++, в старом журнале пользователей C / C ++), и я не могу представить, чтобы они были очень громкими, если бы выбор был настолько плохим.
источник
Технический отчет о производительности C ++ является отличным ориентиром для такого рода вещи. Обратите внимание, что в нем есть раздел, посвященный проблемам встроенного программирования!
Также ++ при упоминании Embedded C ++ в ответах. Стандарт не на 100% в моем вкусе, но он является хорошим ориентиром при принятии решения, какие части C ++ вы можете отказаться.
При программировании для небольших платформ мы отключаем исключения и RTTI, избегаем виртуального наследования и уделяем пристальное внимание количеству виртуальных функций, которые у нас есть.
Однако ваш друг - карта компоновщика: проверяйте ее часто, и вы быстро обнаружите источники кода и раздутие статической памяти.
После этого применяются стандартные соображения по использованию динамической памяти: в такой ограниченной среде, как та, которую вы упомянули, вы можете вообще не использовать динамические выделения. Иногда можно обойтись пулами памяти для небольших динамических выделений или выделением «на основе кадров», когда вы заранее выделяете блок, а потом все это выкидываете.
источник
Я рекомендую использовать компилятор C ++, но ограничить использование специфических функций C ++. Вы можете программировать как C на C ++ (среда выполнения C включена при работе с C ++, хотя в большинстве встроенных приложений вы все равно не используете стандартную библиотеку).
Вы можете использовать классы C ++ и т. Д., Просто
источник
Как разработчик прошивок / встроенных систем, я могу сказать вам, ребята, некоторые причины, по которым C по-прежнему является выбором №1 по сравнению с C ++, и да, я свободно владею ими обоими.
1) Некоторые цели, которые мы разрабатываем, имеют 64 КБ ОЗУ как для кода, так и для данных, поэтому вы должны убедиться, что каждый счетчик байтов, и да, я занимался оптимизацией кода, чтобы сэкономить 4 байта, которые стоили мне 2 часа, и это в 2008 г.
2) Каждая функция библиотеки C проверяется, прежде чем мы впускаем их в окончательный код, из-за ограничения размера, поэтому мы предпочитаем, чтобы люди не использовали div (без аппаратного делителя, поэтому нужна большая библиотека), malloc (потому что у нас нет кучи вся память выделяется из буфера данных в 512-байтовом блоке и требует проверки кода) или другой объектно-ориентированной практики, которая несет большие потери. Помните, что каждая библиотечная функция, которую вы используете, имеет значение.
3) Вы когда-нибудь слышали о термине "наложение"? у вас так мало места для кода, что иногда вам приходится заменять его другим набором кода. Если вы вызываете библиотечную функцию, она должна быть резидентной. Если вы используете его только в функции наложения, вы тратите много места, полагаясь на слишком много объектно-ориентированных методов. Итак, не предполагайте, что какая-либо функция библиотеки C, не говоря уже о C ++, будет принята.
4) Приведение и даже упаковка (где невыровненная структура данных пересекает границу слова) необходимы из-за ограниченного дизайна аппаратного обеспечения (т. Е. Механизма ECC, который подключен определенным образом) или для того, чтобы справиться с аппаратной ошибкой. Вы не можете предполагать слишком много неявно, так зачем же объектно ориентировать это слишком сильно?
5) Худший сценарий: устранение некоторых объектно-ориентированных методов заставит разработчиков задуматься, прежде чем они будут использовать ресурсы, которые могут взорваться (т. Е. Выделение 512 байт в стеке, а не из буфера данных), и предотвратить некоторые из потенциально худших сценариев, которые не тестируются и не исключают весь путь кода вместе.
6) Мы используем много абстракций, чтобы уберечь оборудование от программного обеспечения и сделать код максимально переносимым и удобным для моделирования. Аппаратный доступ должен быть заключен в макрос или встроенную функцию, которые условно скомпилированы между разными платформами, тип данных должен быть приведен как размер байта, а не целевой, использование прямого указателя не допускается (поскольку некоторые платформы предполагают, что ввод-вывод с отображением памяти является как память данных) и т. д.
Я могу придумать больше, но вы поняли идею. У нас, ребят из прошивки, есть объектно-ориентированное обучение, но задача встроенной системы может быть настолько аппаратно-ориентированной и низкоуровневой, что не является высокоуровневой или абстрактной по своей природе.
Кстати, каждая работа по прошивке, в которой я работал, использует контроль версий, я не знаю, откуда вы взяли эту идею.
-какая прошивка парень от SanDisk.
источник
Почему люди так говорят? Вы не узнаете, что делает каждая строка C, если не проверите вывод asm. То же самое и с C ++.
Например, что asm производит этот невинный оператор:
a[i] = b[j] * c[k];
Это выглядит довольно невинно, но компилятор на основе gcc создает этот asm для 8-битного микроконтроллера.
CLRF 0x1f, ACCESS RLCF 0xfdb, W, ACCESS ANDLW 0xfe RLCF 0x1f, F, ACCESS MOVWF 0x1e, ACCESS MOVLW 0xf9 MOVF 0xfdb, W, ACCESS ADDWF 0x1e, W, ACCESS MOVWF 0xfe9, ACCESS MOVLW 0xfa MOVF 0xfdb, W, ACCESS ADDWFC 0x1f, W, ACCESS MOVWF 0xfea, ACCESS MOVFF 0xfee, 0x1c NOP MOVFF 0xfef, 0x1d NOP MOVLW 0x1 CLRF 0x1b, ACCESS RLCF 0xfdb, W, ACCESS ANDLW 0xfe RLCF 0x1b, F, ACCESS MOVWF 0x1a, ACCESS MOVLW 0xfb MOVF 0xfdb, W, ACCESS ADDWF 0x1a, W, ACCESS MOVWF 0xfe9, ACCESS MOVLW 0xfc MOVF 0xfdb, W, ACCESS ADDWFC 0x1b, W, ACCESS MOVWF 0xfea, ACCESS MOVFF 0xfee, 0x18 NOP MOVFF 0xfef, 0x19 NOP MOVFF 0x18, 0x8 NOP MOVFF 0x19, 0x9 NOP MOVFF 0x1c, 0xd NOP MOVFF 0x1d, 0xe NOP CALL 0x2142, 0 NOP MOVFF 0x6, 0x16 NOP MOVFF 0x7, 0x17 NOP CLRF 0x15, ACCESS RLCF 0xfdf, W, ACCESS ANDLW 0xfe RLCF 0x15, F, ACCESS MOVWF 0x14, ACCESS MOVLW 0xfd MOVF 0xfdb, W, ACCESS ADDWF 0x14, W, ACCESS MOVWF 0xfe9, ACCESS MOVLW 0xfe MOVF 0xfdb, W, ACCESS ADDWFC 0x15, W, ACCESS MOVWF 0xfea, ACCESS MOVFF 0x16, 0xfee NOP MOVFF 0x17, 0xfed NOP
Количество производимых инструкций во многом зависит от:
Это особенно верно в крошечном встроенном мире, где процессоры просто не настроены для обработки C. Итак, я бы ответил, что C и C ++ так же плохи, как и друг друга, если вы всегда не проверяете вывод asm, и в этом случае они ничем не хуже друг друга.
Хьюго
источник
Я слышал, что некоторые люди предпочитают C для встроенной работы из-за того, что он проще и, следовательно, легче предсказать фактический код, который будет сгенерирован.
Я лично думаю, что написание C ++ в стиле C (с использованием шаблонов для обеспечения безопасности типов) даст вам много преимуществ, и я не вижу реальной причины не делать этого.
источник
Я не вижу причин использовать C вместо C ++. Все, что вы можете делать на C, вы можете делать и на C ++. Если вы хотите избежать накладных расходов на VMT, не используйте виртуальные методы и полиморфизм.
Однако C ++ может предоставить некоторые очень полезные идиомы без дополнительных затрат. Один из моих любимых - RAII. Классы не обязательно дорогие с точки зрения памяти или производительности ...
источник
Я написал код для встроенной платформы ARM7 на IAR Workbench. Я настоятельно рекомендую полагаться на шаблоны для оптимизации во время компиляции и прогнозирования пути. Избегайте динамических заклинаний, как чумы. Используйте черты / политики в своих интересах, как это предписано в книге Андрея Александреску « Современный дизайн на C ++» .
Я знаю, что этому может быть сложно научиться, но я также уверен, что ваш продукт выиграет от такого подхода.
источник
Хорошая причина, а иногда и единственная, заключается в том, что для конкретной встроенной системы до сих пор нет компилятора C ++. Это относится, например, к микроконтроллерам Microchip PIC . Для них очень легко писать, и у них есть бесплатный компилятор C (на самом деле, небольшой вариант C), но компилятора C ++ в поле зрения нет.
источник
Для системы, ограниченной до 4 КБ оперативной памяти, я бы использовал C, а не C ++, чтобы вы могли быть уверены, что видите все, что происходит. Суть C ++ заключается в том, что очень легко использовать гораздо больше ресурсов (как ЦП, так и памяти), чем кажется на первый взгляд на код. (О, я просто создам еще один BlerfObject, чтобы сделать это ... упс! Кончилась память!)
Вы можете сделать это на C ++, как уже упоминалось (без RTTI, без vtables и т. Д. И т. Д.), Но вы потратите столько же времени, чтобы убедиться, что использование C ++ не ускользнет от вас, как если бы вы делали эквивалент в C .
источник
Человеческий разум справляется со сложностью, оценивая как можно больше, а затем решая, на чем важно сосредоточиться, и отбрасывая или обесценивая остальное. Это вся основа брендинга в маркетинге и, в основном, иконки.
Чтобы бороться с этой тенденцией, я предпочитаю C C ++, потому что он заставляет вас думать о своем коде и о том, как он более тесно взаимодействует с оборудованием - неуклонно близко.
Исходя из многолетнего опыта, я считаю, что C заставляет вас придумывать лучшие решения проблем, в частности, убираясь с дороги и не заставляя вас тратить много времени на удовлетворение ограничения, которое, по мнению некоторых авторов-компиляторов, было хорошей идеей , или выяснить, что происходит «под одеялом».
В этом ключе в языках низкого уровня, таких как C, вы тратите много времени на оборудование и создание хороших пакетов структуры данных / алгоритмов, в то время как языки высокого уровня вы тратите много времени, ломая голову, задаваясь вопросом, что там происходит и почему вы не можете сделать что-то совершенно разумное в вашем конкретном контексте и среде. Превращение вашего компилятора в представление (строгая типизация - худший нарушитель) НЕ является продуктивным использованием времени.
Я, наверное, хорошо вписываюсь в форму программиста - люблю управление. На мой взгляд, это не личный недостаток программиста. Контроль - это то, за что нам платят. Точнее, БЕЗУПРЕЧНЫЙ контроль. C дает вам гораздо больше контроля, чем C ++.
источник
Лично с 4 КБ памяти я бы сказал, что вы не получите намного больше от C ++, поэтому просто выберите ту, которая кажется лучшей комбинацией компилятор / среда выполнения для работы, поскольку язык, вероятно, не будет иметь большого значения.
Обратите внимание, что это также не все о языке, поскольку библиотека также имеет значение. Часто библиотеки C имеют немного меньший минимальный размер, но я могу представить, что библиотека C ++, предназначенная для встраиваемой разработки, урезана, поэтому обязательно протестируйте.
источник
C выигрывает в переносимости - потому что он менее неоднозначен в спецификации языка; поэтому предлагает гораздо лучшую переносимость и гибкость для разных компиляторов и т. д. (меньше головной боли).
Если вы не собираетесь использовать возможности C ++ для удовлетворения потребностей, используйте C.
источник
unsigned mul(unsigned short x, unsigned short y) { return x*y;}
что не имеет побочные эффекты, даже если продукт превышает 2147483647, или что следует рассматриватьvoid get_float_bits(float *fp, uint32_t n) { *(uint32_t)fp = n; }
как возможное изменение значения afloat
].Лично, когда дело доходит до встроенных приложений (когда я говорю «встроенные», я не имею в виду winCE, iPhone и т. Д. Сегодня раздутые встроенные устройства). Я имею в виду устройства с ограниченным ресурсом. Я предпочитаю C, хотя я тоже немного работал с C ++.
Например, устройство, о котором вы говорите, имеет 4 КБ ОЗУ, ну именно по этой причине я бы не стал рассматривать C ++. Конечно, вы можете спроектировать что-то небольшое, используя C ++, и ограничить его использование в вашем приложении, как предлагалось в других сообщениях, но C ++ «может» потенциально в конечном итоге усложнить / раздувать ваше приложение.
Собираетесь ли статически ссылаться? Возможно, вы захотите сравнить статическое фиктивное приложение, используя c ++ vs c. Это может побудить вас вместо этого рассмотреть C. С другой стороны, если вы можете создать приложение на C ++ в соответствии с вашими требованиями к памяти, сделайте это.
ИМХО, вообще во встраиваемых приложениях мне нравится все, что происходит. Кто использует память / системные ресурсы, сколько и почему? Когда они их освобождают?
При разработке для цели с X количеством ресурсов, ЦП, памяти и т. Д. Я стараюсь не использовать эти ресурсы, потому что вы никогда не знаете, какие будущие требования появятся, поэтому вам нужно добавить больше кода в проект, который «предполагалось» быть простым небольшим приложением, но в итоге стало намного больше.
источник
Мой выбор обычно определяется библиотекой C, которую мы решаем использовать, которая выбирается в зависимости от того, что устройство должно делать. Итак, 9 из 10 раз ... это заканчивается uclibc или newlib и C. Ядро, которое мы используем, также оказывает большое влияние на это, или если мы пишем собственное ядро.
Это также выбор точки соприкосновения. У большинства хороших программистов на C нет проблем с использованием C ++ (хотя многие жалуются все время, когда они его используют) .. но я не обнаружил, что обратное верно (по моему опыту).
В проекте, над которым мы работаем (который включает базовое ядро), большинство вещей делается на C, однако небольшой сетевой стек был реализован на C ++, потому что было проще и менее проблематично реализовать сеть с помощью C ++.
В конечном итоге устройство либо будет работать и пройти приемочные испытания, либо нет. Если вы можете реализовать ограничения foo в стеке xx и yy heap, используя язык z, сделайте это, используйте все, что делает вас более продуктивным.
Лично я предпочитаю C, потому что:
Да, мне нравится C ++, но я знаю его не так хорошо, как стандартный C.
Теперь, если вы можете сказать обратное, хорошо, используйте то, что вы знаете :) Если он работает, проходит тесты и т.д .. в чем проблема?
источник
Сколько у вас ROM / FLASH?
4 КБ ОЗУ по-прежнему могут означать, что существуют сотни килобайт флэш-памяти для хранения фактического кода и статических данных. ОЗУ такого размера, как правило, предназначается только для переменных, и если вы будете осторожны с ними, вы можете поместить в память довольно большую программу с точки зрения строк кода.
Однако C ++ имеет тенденцию усложнять размещение кода и данных во FLASH из-за правил конструирования объектов во время выполнения. В C постоянную структуру можно легко поместить во FLASH-память и получить к ней доступ как к объекту аппаратной константы. В C ++ постоянный объект требует, чтобы компилятор оценивал конструктор во время компиляции, что, я думаю, все еще выходит за рамки того, что может сделать компилятор C ++ (теоретически вы могли бы это сделать, но на практике это очень сложно сделать) .
Так что в среде типа «маленькая RAM», «большая FLASH» я бы выбрал C в любой день. Обратите внимание, что хороший промежуточный вариант - это C99, который имеет большинство хороших функций C ++ для кода, не основанного на классах.
источник
В общем нет. C ++ - это супернабор C. Это особенно актуально для новых проектов.
Вы на правильном пути, избегая конструкций C ++, которые могут быть дорогостоящими с точки зрения времени процессора и объема памяти.
Обратите внимание, что некоторые вещи, такие как полиморфизм, могут быть очень ценными - по сути, это указатели на функции. Если вы обнаружите, что они вам нужны, используйте их - с умом.
Кроме того, хорошая (хорошо продуманная) обработка исключений может сделать ваше встроенное приложение более надежным, чем приложение, которое обрабатывает вещи с традиционными кодами ошибок.
источник
Что касается распределения памяти, я могу порекомендовать использовать Quantum Platform и подход с ее конечным автоматом, поскольку он выделяет все, что вам нужно, во время инициализации. Это также помогает уменьшить конфликтные ситуации.
Этот продукт работает как на C, так и на C ++.
источник
Некоторые говорят, что компиляторы C могут генерировать гораздо более эффективный код, потому что им не нужно поддерживать расширенные функции C ++ и поэтому они могут быть более агрессивными в своих оптимизациях.
Конечно, в этом случае вы можете захотеть протестировать два конкретных компилятора.
источник
Единственная причина предпочесть C IMHO, если компилятор C ++ для вашей платформы не в хорошей форме (ошибки, плохая оптимизация и т. Д.).
источник
В книге C ++ для программистов игр есть информация о том, когда размер кода будет увеличиваться в зависимости от возможностей C ++.
источник
У вас есть встроенный в C99. Может быть, вам нравятся ctors, но работа с ними может быть беспорядочной. Если оставшаяся единственная причина не использовать C - это пространства имен, я бы действительно придерживался C89. Это потому, что вы можете захотеть перенести его на немного другую встроенную платформу. Позже вы можете начать писать на C ++ на том же самом коде. Но будьте осторожны со следующим, где C ++ НЕ является надмножеством C. Я знаю, что вы сказали, что у вас есть компилятор C89, но все равно сравнивает C ++ с C99, поскольку первый элемент, например, верен для любого C, начиная с K&R.
sizeof 'a' > 1 в C, а не в C ++. В C у вас есть массивы VLA переменной длины. Пример: func (int i) {int a [i] . В C у вас есть элементы массива переменных VAM. Пример: struct {int b; int m [];} .
источник
Это зависит от компилятора.
Не все встроенные компиляторы реализуют весь C ++, и даже если они это сделают, они могут не справиться с раздуванием кода (что всегда является риском для шаблонов). Протестируйте его с помощью нескольких небольших программ, посмотрите, не возникнут ли у вас проблемы.
Но, учитывая хороший компилятор, нет причин не использовать C ++.
источник
Сразу хочу сказать, что не существует системы с «НЕОГРАНИЧЕННЫМИ» ресурсами. Все в этом мире ограничено, и КАЖДОЕ приложение должно учитывать использование ресурсов, независимо от того, является ли оно ASM, C, JAVA или JavaScript. Манекены, которые выделяют несколько мегабайт «на всякий случай», делают iPhone 7, Pixel и другие устройства крайне утомительными. Неважно, 4кб у вас или 40Гб.
Но с другой стороны, противодействие растрате ресурсов - это время, которое нужно для экономии этих ресурсов. Если требуется еще 1 неделя, чтобы написать простую вещь на C, чтобы сэкономить несколько тиков и несколько байтов, вместо использования C ++, уже реализованного, протестированного и распространенного. Зачем беспокоиться? Это похоже на покупку USB-концентратора. да, вы можете сделать это сами, но будет ли лучше? более надежный? дешевле, если считать свое время?
Попутно подумал - даже мощность от вашей розетки не безгранична. Попробуйте исследовать, откуда он исходит, и вы увидите, что в основном он что-то сжигает. Закон энергии и материала по-прежнему действует: ни один материал или энергия не появляется и не исчезает, а скорее трансформируется.
источник
Я только что нашел пример использования ISO C ++ для встраиваемой разработки, который может заинтересовать тех, кто принимает решение, когда использовать C ++ или C.
Он был предоставлен Бьярном Страуструпом на его домашней странице. :
Чтобы узнать, как ISO C ++ можно использовать для программирования серьезных встроенных систем, см. Стандарты кодирования C ++ для самолетов JSF .
источник
Другой ответ на другой аспект вопроса:
"маллок"
В некоторых предыдущих ответах об этом довольно много говорится. Как вы думаете, почему этот звонок существует? Для действительно небольшой платформы malloc обычно недоступен или определенно необязателен. Реализация динамического распределения памяти имеет смысл, когда у вас есть RTOS в нижней части вашей системы, но до тех пор это чисто опасно.
Без него можно очень далеко продвинуться. Подумайте обо всех старых программах FORTRAN, в которых даже не было подходящего стека для локальных переменных ...
источник
По всему миру существует ряд различных производителей контроллеров, и если вы посмотрите на их конструкции и наборы инструкций, которые необходимо использовать для настройки, вы можете столкнуться с множеством проблем. Основным недостатком языка ассемблера является его зависимость от машины и архитектуры. Очень важно, чтобы разработчик выучил наизусть все инструкции по кодированию для различных контроллеров. Вот почему C стал более популярным во встраиваемых системах, потому что C достаточно высокоуровневый, чтобы абстрагировать алгоритмы и структуры данных от деталей, зависящих от оборудования, что делает исходный код переносимым на большое количество целевого оборудования, архитектурно-независимый язык и очень простой конвертировать и поддерживать код. Но мы действительно видим некоторые языки высокого уровня (объектно-ориентированные), такие как C, C ++, Python, Java и т. Д.
источник
Я рекомендую C ++ с ограничениями и примечаниями.
Время выхода на рынок и ремонтопригодность. Разработка на C ++ проще и быстрее. Так что, если вы находитесь на этапе проектирования, выберите контроллер, достаточно подходящий для использования C ++. (Обратите внимание, что на некоторых рынках с большими объемами требуется как можно более низкая стоимость, где вы не можете сделать этот выбор.)
Скорость. C может быть быстрее, чем C ++, но убедитесь, что прирост скорости невелик. Итак, вы можете перейти на C ++. Разрабатывайте свои алгоритмы, тестируйте их и делайте быстрее только при необходимости (!). Используйте профилировщики, чтобы указать узкие места и переписать их внешне "C" способом для достижения скорости C. (Если это все еще медленно, внедрите эту часть в ASM)
Двоичный размер. Коды C ++ больше, но вот отличный ответ, в котором рассказывается о деталях. Размер скомпилированного двоичного кода данного кода C будет одинаковым, независимо от того, был ли он скомпилирован с использованием компилятора C или C ++. «Размер исполняемого файла зависит не от языка, а от библиотек, которые вы включаете в свой проект». Переход с C ++ , но избежать дополнительных функций, как
streams
,string
,new
,virtual
функция и т.д. Обзор всех функций библиотеки , прежде чем позволить им в конечном коде, из - за ограничение размера (на основании этого ответа)источник