Есть ли какая-либо причина использовать C вместо C ++ для встраиваемой разработки?
https://stackoverflow.com/questions/812717
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Вопрос
У меня есть два компилятора на моем оборудовании C ++ и C89
Я подумываю об использовании C ++ с классами, но без полиморфизма (чтобы избежать vtables).Основными причинами, по которым я хотел бы использовать C ++, являются:
- Я предпочитаю использовать “встроенные” функции вместо определений макросов.
- Я бы хотел использовать пространства имен, поскольку префиксы I загромождают код.
- Я вижу, что C ++ немного безопаснее для типов, в основном из-за шаблонов и подробного приведения.
- Мне действительно нравятся перегруженные функции и конструкторы (используемые для автоматического приведения).
Видите ли вы какие-либо причины придерживаться C89 при разработке для очень ограниченного оборудования (4 КБ оперативной памяти)?
Заключение
Спасибо вам за ваши ответы, они были действительно полезны!
Я продумал эту тему до конца, и я буду придерживаться C главным образом потому, что:
- Легче предсказать фактический код на C, и это действительно важно, если у вас всего 4 КБ оперативной памяти.
- Моя команда состоит в основном из разработчиков на C, поэтому расширенные функции C ++ будут использоваться нечасто.
- Я нашел способ встроить функции в свой компилятор C (C89).
Трудно принять один ответ, поскольку вы дали так много хороших ответов.К сожалению, я не могу создать wiki и принять это, поэтому я выберу один ответ, который заставил меня задуматься больше всего.
Решение
Две причины использовать C вместо C++:
- Для многих встраиваемых процессоров компилятор C++ либо отсутствует, либо за него приходится доплачивать.
- Мой опыт показывает, что значительная часть инженеров встроенного программного обеспечения практически не имеют опыта работы с C++ — либо из-за (1), либо потому, что его, как правило, не преподают на курсах электронной инженерии — и поэтому было бы лучше придерживаться что они знают.
Кроме того, в исходном вопросе и ряде комментариев упоминаются 4 КБ файла. БАРАН.Для типичного встроенного процессора объем оперативной памяти (в основном) не связан с размером кода, поскольку код хранится и запускается из флэш-памяти.
Конечно, следует иметь в виду объем места для хранения кода, но по мере появления на рынке новых, более емких процессоров, это становится менее серьезной проблемой, чем раньше, для всех проектов, кроме наиболее чувствительных к затратам.
Об использовании подмножества C++ для использования со встроенными системами:теперь есть МИСРА С++ стандарт, на который, возможно, стоит обратить внимание.
РЕДАКТИРОВАТЬ: Смотрите также этот вопрос, что привело к спору о C и C++ для встраиваемых систем.
Другие советы
Для очень при ограниченных ресурсах, таких как 4 КБ оперативной памяти, я бы протестировал воду с некоторыми образцами, прежде чем предпринимать много усилий, которые не могут быть легко перенесены обратно в чистую реализацию ANSI C.
Рабочая группа по встроенному C ++ предложила стандартное подмножество языка и стандартное подмножество стандартной библиотеки в дополнение к нему.К сожалению, я потерял счет этим усилиям, когда Журнал пользователя C умер.Похоже, что по адресу <url> есть статья Википедия, и что комитет все еще существует.
Во встроенной среде вам действительно нужно быть осторожным с выделением памяти.Чтобы обеспечить соблюдение этой меры предосторожности, вам может потребоваться определить глобальный 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++ и т. д., просто
- Ограничьте использование виртуальных функций (как вы сказали)
- Ограничьте использование шаблонов
- Для встроенной платформы вам потребуется переопределить оператор new и/или использовать новое размещение для выделения памяти.
Как инженер встроенных систем и встроенных систем, я могу рассказать вам, ребята, о некоторых причинах, по которым C по-прежнему является выбором №1 по сравнению с C++, и да, я свободно владею обоими из них.
1) Некоторые цели, над которыми мы разрабатываем, имеют 64 КБ ОЗУ как для кода, так и для данных, поэтому вам нужно следить за каждым байтом, и да, я занимался оптимизацией кода, чтобы сэкономить 4 байта, что стоило мне 2 часов, и это в 2008.
2) Каждая функция библиотеки C проверяется, прежде чем мы включим их в окончательный код, из-за ограничения размера, поэтому мы предпочитаем, чтобы люди не использовали div (нет аппаратного разделителя, поэтому нужна большая библиотека), malloc (потому что у нас нет кучи). , вся память выделяется из буфера данных частями по 512 байт и требует проверки кода) или другой объектно-ориентированной практики, которая влечет за собой большие штрафы.Помните, что каждая библиотечная функция, которую вы используете, имеет значение.
3) Слышали ли вы когда-нибудь о термине «наложение»?у вас так мало места для кода, что иногда вам приходится заменять его другим набором кода.Если вы вызываете библиотечную функцию, она должна быть резидентной.Если вы используете его только в функции наложения, вы тратите много места, полагаясь на слишком много объектно-ориентированных методов.Поэтому не предполагайте, что какая-либо библиотечная функция C, не говоря уже о C++, будет принята.
4) Приведение и даже упаковка (когда невыровненная структура данных пересекает границу слова) необходимы из-за ограниченной аппаратной конструкции (т.е.механизм ECC, подключенный определенным образом) или справиться с аппаратной ошибкой.Вы не можете неявно предполагать слишком многое, так зачем же слишком много объектно-ориентировать?
5) Наихудший сценарий:Устранение некоторых объектно-ориентированных методов заставит разработчиков думать, прежде чем использовать ресурсы, которые могут взорваться (т.е.выделяя 512 байт в стеке, а не из буфера данных), и предотвратить некоторые потенциальные наихудшие сценарии, которые не проверяются, или полностью исключить весь путь кода.
6) Мы используем много абстракций, чтобы отделить аппаратное обеспечение от программного обеспечения и сделать код максимально переносимым и удобным для моделирования.Доступ к оборудованию должен быть заключен в макрос или встроенную функцию, которые условно скомпилированы между различными платформами, тип данных должен быть приведен к размеру в байтах, а не к конкретному целевому объекту, прямое использование указателя не допускается (поскольку некоторые платформы предполагают, что ввод-вывод с отображением в памяти является то же, что и память данных) и т. д.
Я могу придумать больше, но вы поняли.У нас, разработчиков прошивки, есть объектно-ориентированное обучение, но задача встроенной системы может быть настолько аппаратно-ориентированной и низкоуровневой, что по своей природе она не является высокоуровневой или абстрактной.
Кстати, каждая работа по прошивке, над которой я работал, использует систему контроля версий, я не знаю, откуда вы взяли эту идею.
-какой-то прошивщик от SanDisk.
Лично я предпочитаю C, потому что:
- Я знаю, что делает каждая строка кода (и сколько стоит)
- Я недостаточно хорошо знаю C++, чтобы знать, что делает каждая строка кода (и сколько стоит).
Почему люди так говорят?Ты не знать, что делает каждая строка C, если вы не проверите вывод asm.То же самое касается и C++.
Например, какой ассемблер выдает это невинное утверждение:
a[i] = b[j] * c[k];
Это выглядит довольно невинно, но компилятор на основе gcc создает эту сборку для 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
Количество создаваемых инструкций во многом зависит от:
- Размеры a, b и c.
- хранятся ли эти указатели в стеке или являются глобальными
- находятся ли i, j и k в стеке или являются глобальными
Это особенно актуально в крошечном мире встроенных систем, где процессоры просто не настроены на обработку C.Поэтому мой ответ будет заключаться в том, что C и C++ так же плохи, как друг друга, если только вы не всегда проверяете выходные данные asm, и в этом случае они так же хороши, как друг друга.
Хьюго
Я слышал, что некоторые люди предпочитают C для встроенных работ из-за того, что он проще и, следовательно, легче предсказать фактический код, который будет сгенерирован.
Лично я думаю, что написание C++ в стиле C (с использованием шаблонов для обеспечения безопасности типов) даст вам много преимуществ, и я не вижу реальной причины не делать этого.
Я не вижу причин использовать C вместо C++.Все, что вы можете сделать на C, вы можете сделать и на C++.Если вы хотите избежать накладных расходов VMT, не используйте виртуальные методы и полиморфизм.
Однако C++ может предоставить некоторые очень полезные идиомы без каких-либо дополнительных затрат.Один из моих любимых — RAII.Классы не обязательно требуют больших затрат с точки зрения памяти или производительности...
Я написал код для встроенной платформы ARM7 в IAR Workbench.Я настоятельно рекомендую использовать шаблоны для оптимизации времени компиляции и прогнозирования пути.Избегайте динамического кастинга, как чумы.Используйте черты/политики в своих интересах, как предписано в книге Андрея Александреску: Современный дизайн на C++.
Я знаю, этому может быть трудно научиться, но я также уверен, что ваш продукт выиграет от такого подхода.
Веская причина, а иногда и единственная причина, заключается в том, что до сих пор не существует компилятора C++ для конкретной встраиваемой системы.Так обстоит дело, например, с Микрочип ПОС микроконтроллеры.Для них очень легко писать, и у них есть бесплатный компилятор 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 выигрывает в переносимости - потому что он менее двусмыслен в спецификации языка;таким образом, предлагая гораздо лучшую переносимость и гибкость между различными компиляторами и т. д. (меньше головной боли).
Если вы не собираетесь использовать возможности C++ для удовлетворения своих потребностей, выберите C.
Видите ли вы какие -либо причины придерживаться C89 при разработке для очень ограниченного оборудования (4 КБ ОЗУ)?
Лично, когда речь идет о встроенных приложениях (когда я говорю «встроенные», я не имею в виду WinCE, iPhone и т. д.).раздутые встраиваемые устройства сегодня).Я имею в виду устройства с ограниченным ресурсом.Я предпочитаю C, хотя я тоже немало работал с C++.
Например, устройство, о котором вы говорите, имеет 4кб оперативной памяти, ну, именно по этой причине я бы не стал рассматривать C++.Конечно, вы можете создать что-то небольшое, используя C++, и ограничить его использование в своем приложении, как предлагалось в других сообщениях, но C++ потенциально «может» в конечном итоге усложнить/раздуть ваше приложение под обложками.
Вы собираетесь ссылаться статически?Возможно, вы захотите сравнить статическое фиктивное приложение, используя C++ и C.Это может побудить вас вместо этого рассмотреть вариант C.С другой стороны, если вы можете создать приложение на C++ с учетом ваших требований к памяти, сделайте это.
ИМХО, в целом, в встроенных приложениях мне нравится знать все, что происходит.Кто использует ресурсы памяти/системы, сколько и почему?Когда они их освободят?
При разработке для цели с X количеством ресурсов, процессора, памяти и т. д.Я стараюсь придерживаться минимального использования этих ресурсов, потому что никогда не знаешь, какие будущие требования возникнут, поэтому вам приходится добавлять больше кода в проект, который «должен был» быть простым небольшим приложением, но в конечном итоге стал намного больше.
Мой выбор обычно определяется библиотекой C, которую мы решаем использовать, и которая выбирается в зависимости от того, что устройство должно делать.Итак, 9 из 10 раз..в конечном итоге это будет uclibc или newlib и C.Ядро, которое мы используем, также оказывает большое влияние на это, или если мы пишем собственное ядро.
Это также выбор точки соприкосновения.У большинства хороших программистов на C нет проблем с использованием C++ (хотя многие все время жалуются, что используют его)..но я не обнаружил обратного (по моему опыту).
В проекте, над которым мы работаем (который включает в себя ядро), большинство вещей делается на C, однако небольшой сетевой стек был реализован на C++, потому что было проще и менее проблематично реализовать сетевое взаимодействие с использованием C++.
В конечном итоге устройство либо будет работать и пройдет приемочные испытания, либо нет.Если вы можете реализовать ограничения foo в стеке xx и куче yy, используя язык z, дерзайте, используйте все, что делает вас более продуктивными.
Лично я предпочитаю C, потому что:
- Я знаю, что делает каждая строка кода (и сколько стоит)
- Я недостаточно хорошо знаю C++, чтобы знать, что делает каждая строка кода (и сколько стоит).
Да, я хорошо владею C++, но знаю его не так хорошо, как стандартный C.
Теперь, если вы можете сказать обратное, что ж, используйте то, что вы знаете :) Если это работает, проходит тесты и т. д..в чем проблема?
Сколько у вас ROM/FLASH?
4 КБ ОЗУ по-прежнему могут означать наличие сотен килобайт флэш-памяти для хранения фактического кода и статических данных.Оперативная память такого размера, как правило, предназначена только для переменных, и если вы будете осторожны с ними, вы можете разместить в памяти довольно большую программу с точки зрения строк кода.
Однако C++ имеет тенденцию усложнять размещение кода и данных во флэш-памяти из-за правил создания объектов во время выполнения.В C константную структуру можно легко поместить во FLASH-память и получить к ней доступ как к аппаратно-константному объекту.В C++ постоянный объект потребует, чтобы компилятор вычислил конструктор во время компиляции, что, я думаю, все еще выходит за рамки того, что может сделать компилятор C++ (теоретически вы могли бы это сделать, но на практике это очень и очень сложно сделать). .
Таким образом, в среде с «маленькой оперативной памятью» и «большой флэш-памятью» я бы в любой день использовал C.Обратите внимание, что хорошим промежуточным вариантом является C99, который имеет большинство полезных функций C++ для кода, не основанного на классах.
В общем нет.C++ — это супермножество C.Особенно это будет актуально для новых проектов.
Вы находитесь на правильном пути, избегая конструкций C++, которые могут быть дорогостоящими с точки зрения процессорного времени и объема памяти.
Обратите внимание, что некоторые вещи, такие как полиморфизм, могут быть очень полезными — по сути, это указатели на функции.Если вы обнаружите, что они вам нужны, используйте их с умом.
Кроме того, хорошая (хорошо спроектированная) обработка исключений может сделать ваше встроенное приложение более надежным, чем приложение, которое обрабатывает вещи с традиционными кодами ошибок.
ИМХО, единственная причина предпочесть C — это если компилятор C++ для вашей платформы не в хорошем состоянии (ошибки, плохая оптимизация и т. д.).
Книга C++ для игровых программистов содержит информацию о том, когда размер кода будет увеличен на основе функций C++.
У вас есть встроенный в C99.Возможно, вам нравятся актеры, но подобрать правильных актеров может быть сложно.Если единственная причина не использовать C — это пространства имен, я бы действительно придерживался C89.Это потому, что вы можете захотеть перенести его на немного другую встроенную платформу.Позже вы можете начать писать на C++ тот же код.Но остерегайтесь следующего: C++ НЕ является надмножеством C.Я знаю, вы сказали, что у вас есть компилятор C89, но все равно проводится ли это сравнение C++ с C99, поскольку первый пункт, например, верен для любого C, начиная с K&R.
размер 'а' > 1 в C, а не в C++.В C у вас есть массивы переменной длины VLA.Пример: func(int i){int a[i].В C у вас есть члены массива переменных VAM.Пример: struct{int b;int m[];}.
Сразу хочу сказать, что не существует системы с "НЕОГРАНИЧЕННЫМИ" ресурсами.Все в этом мире ограничено, и КАЖДОЕ приложение должно учитывать использование ресурсов, независимо от того, является ли оно ASM, C, JAVA или JavaScript.Пустышки, выделяющие несколько Мбит «на всякий случай», делают iPhone 7, Pixel и другие устройства крайне тормозными.Неважно, 4кб у вас или 40 Гб.
Но с другой стороны, противодействие растрате ресурсов – это время, которое нужно, чтобы сохранить эти ресурсы.Если для написания простой вещи на C потребуется еще 1 неделя, чтобы сэкономить несколько тактов и несколько байтов вместо использования уже реализованного, протестированного и распространенного C++.Зачем беспокоиться?Это как купить USB-хаб.да, вы можете сделать это сами, но будет ли это лучше?более надежный?дешевле, если посчитать время?
Еще одна мысль: даже мощность вашей розетки не безгранична.Попытайтесь выяснить, откуда он исходит, и вы увидите, что в основном это происходит от чего-то горящего.Закон энергии и материала по-прежнему действует:никакой материал или энергия не появляется и не исчезает, а скорее трансформируется.
Для решения проблем с распределением памяти я могу порекомендовать использовать Quantum Platform и ее подход к конечному автомату, поскольку он выделяет все, что вам нужно, во время инициализации.Это также помогает смягчить проблемы, связанные с разногласиями.
Этот продукт работает как на C, так и на C++.
Это зависит от компилятора.
Не все встроенные компиляторы реализуют весь C++, и даже если они это сделают, они не смогут избежать раздувания кода (что всегда является риском для шаблонов).Проверьте его с помощью нескольких небольших программ и посмотрите, возникнут ли у вас какие-либо проблемы.
Но учитывая хороший компилятор, нет, нет причин не использовать C++.
Я только что нашел пример использования ISO C++ для разработки встроенных систем, который может быть интересен тем, кто принимает решение, использовать ли C++ или C.
Его предоставил Бьерн Страуструп. на его домашней странице:
Чтобы узнать, как ISO C++ можно использовать для серьезного программирования встроенных систем, см. Стандарты кодирования C++ для авиационных транспортных средств JSF.
Разное сообщение с ответом на другой аспект вопроса:
"Маллок"
Некоторые предыдущие ответы довольно много говорят об этом.Почему вы вообще думаете, что этот призыв существует?Для действительно небольшой платформы malloc обычно недоступен или определенно необязателен.Реализация динамического распределения памяти имеет смысл, когда у вас есть RTOS в нижней части вашей системы, но до тех пор это просто опасно.
Без этого можно уйти очень далеко.Просто подумайте обо всех старых программах на FORTRAN, в которых даже не было подходящего стека для локальных переменных...
В мире существует множество различных производителей контроллеров, и когда вы изучите их конструкции и наборы инструкций, которые необходимо использовать для настройки, у вас может возникнуть множество проблем.Основным недостатком языка ассемблера является его зависимость от машины/архитектуры.Это действительно огромная просьба к разработчику выучить наизусть все изложенные там инструкции для написания кода для различных контроллеров.Вот почему C стал более популярным в разработке встроенных систем, поскольку C является достаточно высокоуровневым, чтобы абстрагировать алгоритмы и структуры данных от аппаратно-зависимых деталей, что делает исходный код переносимым на широкий спектр целевого оборудования, независимым от архитектуры языком и очень простым в использовании. конвертировать и поддерживать код.Но мы видим некоторые языки высокого уровня (объектно-ориентированные), такие как C, C++, Python, Java и т. д.развиваются достаточно, чтобы оказаться вне поля зрения разработчиков встраиваемых систем.
В такой ограниченной системе.Просто выберите Ассемблер.Дает вам полный контроль над каждым аспектом и не требует дополнительных затрат.
Вероятно, и намного быстрее, поскольку многие встроенные компиляторы не являются лучшими оптимизаторами (особенно если сравнивать их с современными компиляторами, такими как те, что у нас есть для настольных компьютеров (Intel, Visual Studio и т. д.))
«да, да... но c можно использовать повторно и...».В такой ограниченной системе есть вероятность, что вы все равно не будете повторно использовать большую часть этого кода в другой системе.В той же системе ассемблер можно использовать повторно.
