Есть ли причина использовать C вместо С++ для встроенной разработки?

Ответ 1

Две причины использования C над С++:

• Для многих встроенных процессоров либо нет компилятора С++, либо вам придется дополнительно оплачивать его.
• Мой опыт заключается в том, что значительная доля встроенных инженеров-программистов мало или вообще не имеет опыта работы на С++ - либо из-за (1), либо потому, что он не преподается на электронных машинных степенях - и поэтому было бы лучше придерживаться того, что они знают.

Кроме того, в исходном вопросе и ряде комментариев упоминается 4 Кбайт ОЗУ. Для типичного встроенного процессора объем оперативной памяти (в основном) не связан с размером кода, так как код хранится и запускается с flash.

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

Об использовании подмножества С++ для использования со встроенными системами: теперь существует стандарт MISRA С++, который может стоить смотреть.

EDIT: См. также этот вопрос, что привело к дискуссии о C vs С++ для встроенных систем.

Ответ 2

Для очень ограниченного ресурса, такого как 4 Кбайт ОЗУ, я тестировал воды с некоторыми образцами, прежде чем прикладывать много усилий, которые не могут быть легко перенесены обратно в чистую реализацию ANSI C.

Рабочая группа Embedded С++ предложила стандартное подмножество языка и стандартное подмножество стандартной библиотеки, чтобы пойти с ним. К сожалению, я потерял контроль над этими усилиями, когда C User Journal умер. Похоже, есть статья в Wikipedia и что комитет все еще существует.

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

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

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

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

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

В небольшой встроенной среде вы будете либо напрямую связываться с ядром реального времени, либо работать непосредственно на оборудовании. В любом случае, вам нужно будет убедиться, что ваш код запуска во время выполнения правильно обрабатывает стандартные задачи запуска С++. Это может быть так же просто, как использовать опции правильного компоновщика, но, поскольку обычно существует прямой контроль над источником при включении точки входа reset, вам может потребоваться аудит, чтобы убедиться, что он делает все, Например, на платформе ColdFire, над которой я работал, инструменты dev поставлялись с модулем CRT0.S, в котором присутствовали инициализаторы С++, но закомментированы. Если бы я использовал его прямо из коробки, я бы был озадачен глобальными объектами, конструкторы которых никогда не запускались вообще.

Кроме того, во встроенной среде часто бывает необходимо инициализировать аппаратные устройства до их использования, а если нет ОС и нет загрузчика, то это ваш код, который это делает. Вам нужно будет помнить, что конструкторы для глобальных объектов запускаются до вызова main(), поэтому вам нужно будет изменить локальный CRT0.S(или его эквивалент), чтобы получить эту инициализацию оборудования до вызова глобальных конструкторов. Очевидно, верхняя часть main() слишком поздняя.

Ответ 3

Нет. Любые функции языка С++, которые могут вызвать проблемы (полиморфизм времени выполнения, RTTI и т.д.), Можно избежать при выполнении встроенной разработки. Существует сообщество встроенных разработчиков С++ (я помню чтение столбцов встроенными разработчиками с использованием С++ в старом Журнале пользователей C/С++), и я не могу себе представить, что они были бы очень вокальными, если бы выбор был настолько плохим.

Ответ 4

Технический отчет о производительности С++ - отличное руководство для такого рода вещей. Обратите внимание, что в нем есть раздел о проблемах с встроенным программированием!

Кроме того, ++ об упоминании Embedded С++ в ответах. Стандарт не на 100% соответствует моим вкусам, но это хорошая рекомендация при принятии решения о том, какие части С++ вы можете потерять.

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

Ваш друг - это карта компоновщика, хотя: часто проверяйте ее, и вы быстро обнаружите источники кода и статической памяти.

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

Ответ 5

Я рекомендую использовать компилятор С++, но ограничивая использование специальных возможностей С++. Вы можете запрограммировать, как C в С++ (время выполнения C включено при выполнении С++, хотя в большинстве встроенных приложений вы все равно не используете стандартную библиотеку).

Вы можете продолжить и использовать классы С++ и т.д., просто

• Ограничьте использование виртуальных функций (как вы уже сказали)
• Ограничьте использование шаблонов
• Для встроенной платформы вы хотите переопределить оператор new и/или использовать новое место размещения для размещения памяти.

Ответ 6

Как программист/встроенный системный инженер, я могу сказать вам, что некоторые из причин, почему C по-прежнему являются # 1 выбором по сравнению с С++, и да, я свободно говорю обо всех них.

1) Некоторые цели, которые мы разрабатываем, имеют 64 КБ ОЗУ для кода и данных, поэтому вам нужно убедиться, что каждый байт подсчитан, и да, я занимался оптимизацией кода, чтобы сохранить 4 байта, которые стоили мне 2 часа, и что в 2008 году.

2) Каждая функция библиотеки C рассматривается перед тем, как мы разрешим их в конечном коде из-за ограничения по размеру, поэтому мы предпочитаем, чтобы люди не использовали разделение (нет аппаратного разделителя, поэтому нужна большая библиотека), malloc (потому что мы не имеют кучи, вся память выделяется из буфера данных в блоке объемом 512 байт и должна быть проверена кодом) или другая объектно-ориентированная практика, несущая большой штраф. Помните, что каждая функция библиотеки, которую вы используете, подсчитывает.

3) Когда-либо слышали о терминах оверлей? у вас так мало места для кода, что вам иногда приходится заменять другим набором кода. Если вы вызываете библиотечную функцию, функция библиотеки должна быть резидентной. Если вы используете его только в оверлейной функции, вы тратите много места, полагаясь на слишком много объектно-ориентированных методов. Итак, не предполагайте, что любая функция библиотеки C, не говоря уже о С++, будет принята.

4) Кастинг и даже упаковка (где неровная структура данных пересекает границу слова) необходимы из-за ограниченного аппаратного дизайна (то есть механизма ECC, который подключен определенным образом) или для устранения аппаратной ошибки. Вы не можете предположить слишком много неявно, поэтому почему объект слишком ориентирован?

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

6) Мы используем много абстракций, чтобы поддерживать аппаратное обеспечение от программного обеспечения и сделать код как можно более переносимым, а также дружественным к симуляции. Доступ к аппаратным средствам должен быть завернут макрокомандой или встроенной функцией, которая условно скомпилирована между различными платформами, тип данных должен быть отличен как размер байта, а не целевой, использование прямого указателя не допускается (поскольку какая-то платформа предполагает, что входы/выходы, отображаемые в память, являются как память данных) и т.д.

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

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

-простой прошивки от SanDisk.

Ответ 7

Мое личное предпочтение - C, потому что:

• Я знаю, что делает каждая строка кода (и стоит)
• Я не знаю С++ достаточно хорошо, чтобы знать, что делает каждая строка кода (и затраты)

Почему люди так говорят? Вы не знаете, что делает каждая строка C, если вы не проверяете выход asm. То же самое касается С++.

Например, какой 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

Количество созданных инструкций зависит от:

• Размеры a, b и c.
• сохраняются ли эти указатели в стеке или глобальны
• находятся ли i, j и k в стеке или глобальны

Это особенно верно в крошечном вложенном мире, где процессоры просто не настроены для обработки C. Таким образом, мой ответ будет заключаться в том, что C и С++ так же плохи, как и каждый другой, если вы не всегда рассматриваете выход asm в в этом случае они так же хороши, как и другие.

Уго

Ответ 8

Я слышал, что некоторые люди предпочитают C для встроенной работы из-за того, что проще и, следовательно, легче предсказать фактический код, который будет сгенерирован.

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

Ответ 9

Я не вижу причин использовать C вместо С++. Что бы вы ни делали на C, вы можете сделать это и на С++. Если вы хотите избежать накладных расходов VMT, не используйте виртуальные методы и полиморфизм.

Однако С++ может предоставить некоторые очень полезные идиомы без накладных расходов. Один из моих фаворитов - RAII. Классы не нужны дорогие с точки зрения памяти или производительности...

Ответ 10

Я написал код для встроенной палитры ARM7 в IAR Workbench. Я настоятельно рекомендую полагаться на шаблоны для оптимизации времени компиляции и предсказания пути. Избегайте динамического каста, такого как чума. Используйте черты/политики в ваших интересах, как это предписано в книге Андрея Александреску, Современный дизайн С++.

Я знаю, это может быть трудно узнать, но я также уверен, что ваш продукт выиграет от этого подхода.

Ответ 11

Хорошая причина, и иногда единственная причина заключается в том, что компилятор С++ для конкретной встроенной системы еще не существует. Это относится, например, к микроконтроллерам Microchip PIC. Их очень легко написать, и у них есть бесплатный компилятор C (на самом деле, небольшой вариант C), но компилятор С++ отсутствует.

Ответ 12

Для системы с ограничением до 4 КБ, я бы использовал C, а не С++, чтобы вы могли убедиться, что все, что происходит. Дело с С++ заключается в том, что очень просто использовать гораздо больше ресурсов (как для процессора, так и для памяти), чем это похоже на поиск кода. (О, я просто создаю еще один BlerfObject, чтобы сделать это... извините! Из памяти!)

Вы можете сделать это на С++, как уже упоминалось (нет RTTI, нет vtables и т.д. и т.д.), но вы потратите столько времени, чтобы ваше использование на С++ не уклонилось от вас, как вы делали эквивалентно в C.

Ответ 13

Человеческий ум имеет дело со сложностью, оценивая как можно больше, а затем решая, на что важно сосредоточиться, и отбрасывая или обесценивая остальных. Это все основания для брендинга в маркетинге, и в основном, иконки.

Чтобы бороться с этой тенденцией, я предпочитаю C на С++, потому что это заставляет вас задуматься о вашем коде и о том, как он взаимодействует с оборудованием более тесно - неуклонно закрывается.

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

В этом ключе языки низкого уровня, такие как C, вы тратите много времени на аппаратное обеспечение и создаете хорошие структуры данных/алгоритмов, в то время как языки высокого уровня вы тратите много времени, царапая голову, думая, что происходит там, и почему вы не можете сделать что-то совершенно разумное в своем конкретном контексте и окружающей среде. Избиение вашего компилятора в подчинение (сильная типизация является худшим нарушителем) НЕ является продуктивным использованием времени.

Я, наверное, хорошо подгоняю форму программиста - мне нравится контроль. На мой взгляд, это не недостаток личности для программиста. Контроль - это то, за что нам платят. Более конкретно, БЕСПЛАТНО контролировать. C дает вам гораздо больше контроля, чем С++.

Ответ 14

Лично с 4 Кб памяти я бы сказал, что вы не получаете намного больше пробега из С++, поэтому просто выберите тот, который кажется лучшим компилятором/временем выполнения для работы, поскольку язык, вероятно, не будет иметь большого значения,

Обратите внимание, что это также не все о языке, так как и библиотека имеет значение. Часто C libs имеют немного меньший минимальный размер, но я могу представить, что С++ lib, ориентированный на встроенную разработку, сокращается, поэтому обязательно проверяйте.

Ответ 15

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

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

Ответ 16

Вы видите какую-либо причину придерживаться C89 при разработке для очень ограниченного аппаратное обеспечение (4 КБ ОЗУ)?

Лично, когда дело доходит до встроенных приложений (когда я говорю "встроенный", я не имею в виду winCE, iPhone и т.д. раздутые встроенные устройства сегодня). Я имею в виду устройства с ограниченными ресурсами. Я предпочитаю C, хотя я тоже работал с С++.

Например, устройство, о котором вы говорите, имеет 4kb ОЗУ, и именно по этой причине я бы не стал рассматривать С++. Конечно, вы можете создать что-то маленькое с помощью С++ и ограничить его использование в своем приложении, как предполагали другие сообщения, но С++ "может" потенциально может осложнить/раздуть ваше приложение под обложками.

Вы собираетесь связать статически? Вы можете сравнить статическое фиктивное приложение с помощью С++ vs c. Это может привести вас вместо этого рассмотреть C. С другой стороны, если вы можете создать приложение С++ в своих требованиях к памяти, пойдите для него.

ИМХО, В общем, во встроенных приложениях мне нравится все, что происходит. Кто использует ресурсы памяти/системы, сколько и почему? Когда они освобождают их?

При разработке для цели с X количеством ресурсов, процессором, памятью и т.д. Я стараюсь оставаться на нижней стороне использования этих ресурсов, потому что вы никогда не знаете, какие будущие требования придут, таким образом, вы добавите больше кода для проект, который был "предположительно", является простым небольшим приложением, но в конечном итоге становится намного больше.

Ответ 17

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

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

Ответ 18

Мой выбор обычно определяется библиотекой C, которую мы решили использовать, которая выбирается на основе того, что нужно делать устройству. Итак, 9/10 раз. В итоге он становится uclibc или newlib и C. Ядро, которое мы используем, также сильно влияет на это, или если мы пишем наше собственное ядро.

Его также выбор общего основания. У большинства хороших программистов C нет проблем с использованием С++ (хотя многие жалуются на все время их использования). Но я не нашел обратное, чтобы быть правдой (по моему опыту).

В проекте, над которым мы работаем (что связано с ядром ядра), большинство вещей выполняется на C, однако на С++ был реализован небольшой сетевой стек, поскольку было проще и менее проблематично реализовывать сети с использованием С++.

Конечным результатом является то, что устройство будет либо работать, либо сдавать приемочные тесты, либо оно не будет. Если вы можете реализовать foo в xx stack и yy ограничениях кучи, используя язык z, пойдите для этого, используйте то, что делает вас более продуктивным.

Мое личное предпочтение - C, потому что:

• Я знаю, что делает каждая строка кода (и стоит)
• Я не знаю С++ достаточно хорошо, чтобы знать, что делает каждая строка кода (и затраты)

Да, мне комфортно с С++, но я не знаю, как и стандартный C.

Теперь, если вы можете сказать обратное этому, ну, используйте то, что вы знаете:) Если это работает, проходит тесты и т.д., в чем проблема?

Ответ 19

Сколько у вас ROM/FLASH?

4kB оперативной памяти все еще может означать, что есть сотни килобайт FLASH для хранения фактического кода и статических данных. ОЗУ такого размера имеет смысл только для переменных, и если вы будете осторожны с теми, которые могут поместиться в большую программу с точки зрения строк кода.

Однако С++ имеет тенденцию усложнять задачу ввода кода и данных во FLASH из-за правил построения времени выполнения для объектов. В C постоянная структура может быть легко помещена во флэш-память и доступна как объект с аппаратной константой. В С++ постоянный объект требует, чтобы компилятор оценивал конструктор во время компиляции, который, я думаю, все еще находится вне того, что может сделать компилятор С++ (теоретически, вы могли бы это сделать, но на практике это очень сложно),

Итак, в "маленькой ОЗУ", "большой FLASH" среде, я бы пошел с C в любой день. Обратите внимание, что хороший промежуточный выбор я C99, который имеет большинство приятных функций С++ для неклассического кода.

Ответ 20

В общем нет. С++ - это супер-набор C. Это будет особенно актуально для новых проектов.

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

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

Кроме того, хорошая (хорошо продуманная) обработка исключений может сделать ваше встроенное приложение более надежным, чем приложение, которое обрабатывает вещи с помощью традиционных кодов ошибок.

Ответ 21

Единственная причина, чтобы предпочесть C IMHO, была бы, если бы компилятор С++ для вашей платформы не был в хорошей форме (багги, слабая оптимизация и т.д.).

Ответ 22

У вас встроенный C99. Может быть, вам нравятся ctors, но дело в том, чтобы правильно управлять dtors, может быть беспорядочным. Если оставшаяся причина не использовать C - это пространства имен, я бы действительно придерживался C89. Это связано с тем, что вы можете перенести его на несколько другую встроенную платформу. Вы можете позже начать писать на С++ на том же коде. Но будьте осторожны: С++ не является супермножеством C. Я знаю, что вы сказали, что у вас есть компилятор C89, но все равно это сравнение С++ с C99, так как первый элемент, например, верен для любого C, так как K & R.

sizeof 'a' > 1 в C, а не на С++. В C вы имеете массивы переменной длины VLA. Пример: func (int i) {int a [i]. В C у вас есть члены массива переменных VAM. Пример: struct {int b; int m [];}.

Ответ 23

Просто хочу сказать, что нет системы с ресурсами "UNLIMITED". Все в этом мире ограничено, и КАЖДОЕ приложение должно учитывать использование ресурсов независимо от его ASM, C, JAVA или JavaScript. Манекены, которые выделяют несколько Mbs "просто для того, чтобы быть уверенным", делают iPhone 7, Pixel и другие устройства крайне неудобными. Независимо от того, имеете ли вы 4 КБ или 40 ГБ.

Но с другой стороны, чтобы противостоять трате ресурсов - это время, затрачиваемое на сохранение этих ресурсов. Если требуется добавить одну неделю, чтобы написать простую вещь в C, чтобы сохранить несколько тиков и несколько байтов вместо использования С++, уже реализованного, протестированного и распределенного. Зачем беспокоиться? Это похоже на покупку USB-концентратора. да, вы можете сделать это сами, но будет ли лучше? более надежный? дешевле, если вы посчитаете свое время?

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

Ответ 24

В случае проблемы с распределением памяти я могу порекомендовать использовать платформу Quantum Platform и ее подход к компьютеру, поскольку он выделяет все, что вам нужно, во время инициализации. Это также помогает смягчить конфликтные проблемы.

Этот продукт работает как на C, так и на С++.

Ответ 25

В книге С++ для Game Programmers содержится информация о том, когда размер кода будет увеличен на основе функций из С++.

Ответ 26

Это зависит от компилятора.

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

Но, учитывая хороший компилятор, нет, нет причин не использовать С++.

Ответ 27

Я только что нашел пример того, как использовать ISO С++ для встроенной разработки, что может быть интересно для тех, кто принимает решение при использовании С++ или C.

Это было предоставлено Bjarne Stroustrup на своей домашней странице:

Для ознакомления с тем, как ISO С++ можно использовать для программирования серьезных встроенных систем, см.

Ответ 28

Различные ответы на другой вопрос:

"таНос"

Некоторые предыдущие ответы говорят об этом немного. Почему вы даже думаете, что вызов существует? Для действительно небольшой платформы malloc имеет тенденцию быть недоступным или определенно необязательным. Реализация динамического распределения памяти имеет смысл, когда вы получаете RTOS в нижней части вашей системы, но до тех пор это просто опасно.

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

Ответ 29

В такой ограниченной системе. Просто пойдите для Ассемблера. Дает вам полный контроль над каждым аспектом и не дает накладных расходов.

Вероятно, намного быстрее, поскольку многие встроенные компиляторы не являются лучшими оптимизаторами (особенно, если сравнивать их с современными компиляторами, такими как те, что у нас есть для рабочего стола (intel, visual studio и т.д.))

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