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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я могу придумать больше, но вы получаете идею. Ребята из США имеют объектно-ориентированное обучение, но задача встроенные системы могут быть ориентированы так, скобяными и низком уровне, что это не высокий уровень или abstractable природой.

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

-какой-то парень с прошивкой из SanDisk.

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

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

почему люди говорят это? Вы не знайте, что делает каждая строка 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

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

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

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

Угу

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

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

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

однако C++ может предоставить некоторые очень полезные идиомы без накладных расходов. Один из моих любимых-РАИИ. Классы не являются необходимыми дорогими с точки зрения памяти или производительности...

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

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

хорошая причина, а иногда и единственная причина в том, что до сих пор нет компилятора C++ для конкретной встроенной системы. Это относится, например, к микрочип PIC микро-контроллерах. Они очень просты в написании, и у них есть бесплатный компилятор C (на самом деле, небольшой вариант C), но компилятора C++ не видно.

для системы, ограниченной 4K ОЗУ, я бы использовал C, а не c++, просто чтобы вы могли быть уверены, что видите все, что происходит. Дело в том, что с c++ очень легко использовать гораздо больше ресурсов (как CPU, так и память), чем кажется, глядя на код. (О, я просто создам еще один BlerfObject для этого...упс! из памяти!)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

конечный результат, прибор или будет работать и пройдет приемочные испытания или он не будет. Если вы можете реализовать foo в XX стеке и YY ограничениях кучи с помощью языка z, перейдите к нему, используйте все, что делает вас больше продуктивный.

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

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

Да, мне удобно с C++, но я не знаю его так же хорошо, как стандартный C.

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

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

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

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

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

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

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

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

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

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

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

У вас есть встроенный в C99. Может быть, вам нравятся ctors, но бизнес получения dtors может быть грязным. Если оставшаяся единственная причина не использовать 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 [];}.

просто хочу сказать, что нет системы с "неограниченными" ресурсами. Все в этом мире ограничено, и каждое приложение должно учитывать использование ресурсов независимо от того, является ли его ASM, C, JAVA или JavaScript. Манекены, которые выделяют несколько Мб "просто чтобы быть уверенными", делают iPhone 7, Pixel и другие устройства чрезвычайно тяжелыми. Независимо от того, есть ли у вас 4kb или 40 Gb.

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

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

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

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

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

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

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

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

его предоставил Бьярне Страуструп на своей странице:

Посмотрите, как ISO C++ может использоваться для серьезного программирования встроенных систем, см. JSF air vehicle c++ стандарты кодирования.

другой ответ на другой аспект вопроса:

"Танос"

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

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

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

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

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