Используя C++ во встроенной среде

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

Мне особенно нравится абстракция, которую мы можем построить с помощью C ++, особенно для устройств ввода-вывода. . Итак, у нас может быть класс для UART и класс для GPIO, а что нет. Это чище, чем наличие кучи функций (ИМХО).

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

Это особенно относится к современным платформам с 32-битной архитектурой. Но C, безусловно, по-прежнему является предпочтительным выбором для более ограниченных сред (как и ассемблер для 8-битных или 4-битных целей).

Итак, это действительно сводится к ресурсам, которые предоставляет ваша целевая платформа, и сколько из этих ресурсов вы скорее всего, действительно потребуются, т.е. если вы можете позволить себе «роскошь» разработки встраиваемых систем на C ++ (или даже на Java, если на то пошло), потому что вы знаете, что у вас вряд ли возникнут проблемы с памятью или ограничениями ЦП.

В настоящее время многие современные встраиваемые платформы (игровые консоли, мобильные телефоны, КПК и т. Д.) Действительно стали очень полезными целями, с архитектурами RISC, несколькими МБ ОЗУ и аппаратным ускорением 3D.

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

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

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

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

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

Я не знаю об «общем консенсусе», только о компании, в которой я работаю (которая много занимается разработкой мобильных телефонов, автомобильных навигационных систем, сажевых фильтров и т. Д.).

Основной недостаток, с которым я столкнулся при использовании C ++ на встроенных платформах в отличие от C, заключается в том, что он не такой переносимый - есть еще много случаев компиляторов, которые не придерживаются стандарта, что может вызвать проблемы, если вам нужно чтобы собрать свой код с более чем одним компилятором или сразу иметь ошибки в реализации. Кроме того, существуют среды, в которых код C ++ просто не запускается - проблемы BREW с перемещаемым кодом и его «родным ООП» не очень хорошо сочетаются с «обычными» классами C ++ и наследованием.

В конце концов, если вы нацелены только на 1 платформу, я бы сказал, используйте все, что вы думаете "

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

Например, на смартфоне, таком как устройство, работающее под управлением Windows CE 5, почти все код - C ++, в том числе и в операционной системе. На C или на ассемблере пишутся только небольшие биты.

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

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

One of the few things I tend to agree with Linus is his opinion about C++ http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Besides this, if you really really want to use C++ you might want to have a look at http://www.caravan.net/ec2plus/ which describes Embedded C++, or better to say you should not use in C++ for embedded systems.

Now a days it will all boil down to the C++ runtime support of the platform. You're likely to find a way to compile C++ code down to almost any embedded platform with GCC, but if you can't find a suitable C++ runtime for the platform your efforts will be futile, unless you write your own C++ runtime.

The big thing keeping us with using C++ for a long time was the VxWorks support for it, which truly sucked. That supposidly has gotten better on VxWorks 6 (yes, it's been out a while... good 'ole vendor lock-in and lack of company vision has kept us stuck on VxWorks 5.5).

So for us it's mostly a question of the environment. After that, C++ can obviously be just as good as C... it's a matter of people understanding what their tool does and how to use it. C++ may make it easier to write incredibly inefficient code, but that doesn't mean we have to succomb to it.

В настоящее время я борюсь с проблемой исключений во встроенном приложении Linux. Мы пытаемся перенести программное обеспечение, написанное для другой платформы, которая, похоже, хорошо поддерживает исключения, но новые инструменты компилятора (порт gcc) сообщают об ошибках при создании файла eh_frame. Я был против использования исключений для этого инструмента, но разработчик заверил меня, что современные компиляторы будут его хорошо поддерживать.

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