Есть ли причина использовать C вместо C ++ для разработки встраиваемых систем? - PullRequest
77 голосов
/ 01 мая 2009

Вопрос

На моем оборудовании есть два компилятора C ++ и C89

Я думаю об использовании C ++ с классами, но без полиморфизма (чтобы избежать vtables). Основные причины, по которым я хотел бы использовать C ++:

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

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

Заключение

Спасибо за ваши ответы, они были действительно полезны!

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

  1. Проще предсказать фактический код на C, и это действительно важно, если у вас есть только 4 КБ ОЗУ.
  2. Моя команда состоит в основном из разработчиков C, поэтому расширенные возможности C ++ не будут часто использоваться.
  3. Я нашел способ встроить функции в мой компилятор C (C89).

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

Ответы [ 30 ]

1 голос
/ 01 мая 2009

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

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

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

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

1 голос
/ 01 мая 2009

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

1 голос
/ 02 мая 2009

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

1 голос
/ 02 мая 2009

У вас есть встроенный в 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 [];} .

0 голосов
/ 26 октября 2018

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

0 голосов
/ 01 мая 2009

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

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

0 голосов
/ 26 мая 2009

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

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

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

0 голосов
/ 22 мая 2009

Разное ответное сообщение на другой аспект вопроса:

"таНос"

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

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

0 голосов
/ 06 мая 2009

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

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

Чтобы узнать, как ISO C ++ можно использовать для программирования серьезных встраиваемых систем, см. стандарты кодирования C ++ для воздушных транспортных средств JSF *1008*.

0 голосов
/ 02 мая 2009

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

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

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

...