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

Question

Я нахожусь в процессе разработки библиотеки программного обеспечения, которая будет использоваться для встраиваемых систем, таких как чип ARM или TI DSP (в основном для встраиваемых систем, но было бы также неплохо, если бы ее также можно было использовать в среде ПК ). Очевидно, что это довольно широкий спектр целевых систем, поэтому возможность легко портировать на разные системы является приоритетом. Библиотека будет использоваться для взаимодействия с конкретным оборудованием и запуска некоторых алгоритмов.

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

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

Есть ли другие факторы, которые я должен учитывать? Правильно ли мое мышление?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Большие встроенные системы, такие как основанные на ARM, как правило, очень похожи на настольные системы с точки зрения доступности цепочки инструментов. Фактически, многие из тех же инструментов, доступных для настольных компьютеров, также могут генерировать код для запуска на компьютерах на основе ARM (например, многие из них используют порты gcc / g ++). Меньше разнообразия для TSP DSP (и больший упор на качество сгенерированного кода, чем на функции исходного кода), но по-прежнему есть, по крайней мере, пара респектабельных компиляторов C ++.

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

Answer 8

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

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

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

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