Разрабатывая библиотеку встроенного программного обеспечения, C или C++?

Компиляторы C ++ для встроенных платформ намного ближе к 83-м годам C с классами, чем 98-е годы C ++, не говоря уже о C ++ 0x. Например, некоторые платформы, которые мы используем, все еще компилируемые со специальной версией GCC, сделанной из GCC-2.95!

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

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

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

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

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

В целом, гораздо проще использовать хорошо спроектированную C C ++, чем наоборот. Я взял этот подход с несколькими наборами кода, включая разборные файлы Intel Hex, простой анализатор команды, манипулируя объектами синхронизации, FSM Frameworks и т. Д. Я планирую сделать простой анализатор XML в какой-то момент.

На ПК C ++ не является проблемой вообще - высококачественные компиляторы чрезвычайно широко распространены, и почти каждый компилятор C непосредственно связан с компилятором C ++, который довольно хорош, хотя есть Несколько исключений, таких как LCC, и вновь возрожденные PCC.

Более крупные встроенные системы, такие как те, которые на основе рычага, как правило, очень похожи на настольные системы с точки зрения доступности цепи инструментов. Фактически, многие из одинаковых инструментов, доступных для настольных машин, также могут генерировать код для работы на компьютерах на основе ARM (например, множество из них используют порты GCC / G ++). Там меньше разнообразия для Ti DSPS (и большего упор на качество сгенерированного кода, чем функции исходного кода), но есть по крайней мере пару респектабельных компиляторов C ++.

Если вы хотите работать с меньшими встроенными системами, ситуация изменяется в спешке. Если вы хотите иметь возможность нацелить что-то вроде PIC или AVR, C ++ не очень много варианта. Теоретически вы можете получить (например) Comeau для создания пользовательского порта, который сгенерированный код, который вы можете компиляторуться на то, что Compiler C Compiler - но шансы довольно хороши, что даже если вы сделали, это не будет работать очень хорошо. Эти системы действительно просто слишком ограничены (особенно в размере памяти) для C ++, чтобы они хорошо поместили их.

Вот совершенно другой аргумент C ++ - VS-C: стабильные abis. Если ваша библиотека экспортирует C ABI, он может быть скомпилирован любым компилятором, который работает в системе, поскольку C ABIS, как правило, стандарты платформы. Если ваша библиотека экспортирует C ++ ABI, он может быть скомпилирован только с соответствующим компилятором - потому что C ++ ABI обычно не являются стандартами платформы, и часто отличаются от компилятора к компилятору и даже версии для версии.

Интересно, что один из редких исключений из этого является рука; Есть спецификация ABI ABI C ++ ABI, и все соответствующие компиляторы ARM следуют за ним. Это не соответствует x86; На X86 вам повезет, если библиотека C ++ скомпилирована с версией GCC 4.1, будет правильно ссылаться с приложением, скомпилированным с GCC 4.4, и даже не спрашиваю о 3,4,6.

Даже если вы экспортируете C ABI, вы можете возникнуть проблемы. Если ваша библиотека использует C ++ внутри внутренне, она будет ссылаться на libstdc ++ для вещей в пространстве имен C ++ STD :::. Если ваш пользователь компилирует приложение C ++, которое использует вашу библиотеку, они также ссылаются на libstdc ++ - и поэтому общее приложение может быть связано с libstdc ++ дважды, и их libstdc ++ не может быть совместимо с вашим libstdc ++, который может (или поэтому я понимаю ) привести к нечетным ошибкам от пересечения двух. Значительно менее вероятно, но все же возможно.

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

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

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

, безусловно, хорошая поддержка C ++ для рук. ARM У своего собственного компилятора и G ++ также могут генерировать код ABI ARM. Когда дело доходит до DSP, вам придется посмотреть на инструментарий, чтобы решить, что вы собираетесь делать. Помните, что библиотека, которая поставляется с DSP, вполне может не реализовать полную стандартную библиотеку C или C ++.

C ++ подходит для низкоуровневого встроенного развития и используется в ядре Symbianos. Сказав это, вы должны держать вещи как можно просто.

• Избегайте исключения, которые могут потребовать дополнительную поддержку библиотеки, чем то, что присутствует (поэтому использовать новый (STD :: Nothrow) Foo вместо новых Foo).
• Избегайте максимально возможных распределений памяти, и сделайте их как можно раньше.
• Избегайте сложных шаблонов.
• Будьте в курсе, что шаблоны могут раздувать ваш код.

Я видел много жалоб, что C ++ «раздувается» и не подходит для встроенных систем.

Однако в интервью STRUSTRUP и Sutter, Bjarne Strourstrup упомянул, что он видел тяжело шаблон C ++, идущий в (IIRC) тормозные системы BMW, а также в системах ракетных инструментов для истребителей.

Что я убираю из этого, заключается в том, что эксперты языка могут генерировать сложный, эффективный код в C ++, который, безусловно, подходит для встроенных систем. Тем не менее, «C с классами» [1] программист, который не знает, что язык наизнанку, будет генерировать раздутый код, который неуместно.

Вопрос сводится к, как всегда: в каком языке ваша команда доставит лучший продукт?

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