C ++ на микроконтроллерах малого размера

Question

Мне кажется, что люди постоянно уклоняются от использования C ++ на микроконтроллерах или, скорее, яростно выступают против этого, но я не могу понять, почему.Если вы держитесь подальше от больших библиотек C ++ (например, STL) и не пытаетесь использовать сложные функции, такие как RTTI или обработка исключений, действительно ли есть заметная разница между C и C ++?Влияет ли виртуальное наследование на сложность или занимаемую площадь?Я бы подумал, что это будет немного дополнительной памяти, но большая часть сложности будет обрабатываться компилятором, но опять же, я мало что знаю об этой темной магии.Я просто не понимаю, почему люди довольно непреклонны в использовании C, за исключением, может быть, нескольких архитектур, для которых нет компиляторов C ++ (если они есть).Кажется, что преимущества модульности и шаблонов будут простыми, даже если вы не сможете использовать свой cin или cout.

Я спрашиваю, потому что я провожу некоторые исследования для некоторых хобби-проектов, которые мне бы хотелосьработать на.В идеале я хотел бы работать с C ++ строго для возможности красиво модульных вещей, в отличие от подхода C SomeClass_SomeMethod (struct object * this ...) к «объектно-ориентированности».(Я бы предпочел объект Pascal для этих проектов, но, увы, поддержка этого языка не совсем звездная ...) Я бы предпочел не переходить на гораздо более мощный микропроцессор, потому что A. для проектов, которые я делаю, яМне не нужны тонны ресурсов ... Я не планирую писать 60 фильтров состояния Калмана или кодировать видео 1080p B. (настоящий кикер) Я бы хотел использовать процессоры, доступные в пакетах DIP и QFP.Я хотел бы иметь возможность создавать прототипы без пайки или выпекания чего-либо в моей тостерной печи.

Есть мысли?

Answer 1

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

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

EETimes / Embedded.com опубликовал ряд статей на эту тему:

• Лучше даже на самых низких уровнях - Дэн Сакс
• Встроенный C ++ дает меньший код - Джон Карбон
• Почему C ++ является жизнеспособной альтернативой C в разработке встраиваемых систем - Фергус Болгер
• Плохие причины для отказа от C ++ - Дэн Сакс
• Эффективное использование C ++ во встроенных приложениях - Mentor Graphics / Cesar A. Quiroz
• Неэффективность C ++, факты или вымысел? - IAR Systems / Андерс Лундгрен

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

Answer 2

Комитет C ++ написал (бесплатно) технический отчет на эту тему.

Answer 3

Конечно, это сильно варьируется.

Я бы не использовал виртуальное наследование на «маленьком» MCU. Я бы даже не использовал кучу.

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

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

GCC - самый функциональный и широко доступный компилятор C ++, доступный для встроенных платформ. Тем не менее, его платформа поддержки очень неравномерно. Если у вас есть неограниченные ресурсы, EDG сообщает, что они предоставят поддержку, превосходящую Comeau, на «вашей» встроенной платформе.

Answer 4

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

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

Во-вторых, существует миф о том, что C ++ является объектно-ориентированным, а C - нет.Модное словечко-объектная ориентация сводится к трем вещам:

• 1) Модульная конструкция с автономными объектами, которые тесно не связаны ни с чем другим.Это очень важный атрибут любой программы.
• 2) Частная инкапсуляция данных и сокращение объема данных.Это довольно важный атрибут любой программы.
• 3) Полиморфизм классов: классы, которые наследуют другие классы и ведут себя по-разному при наследовании.Полиморфизм весьма полезен, но гораздо меньше в небольших встроенных системах.

1) может быть полностью реализован как на C, так и на C ++, это вопрос проектирования программ, а не синтаксиса языка.И это самый важный атрибут ОО на сегодняшний день!К сожалению, ни в одном языковом стандарте нет ничего, что говорило бы о том, как разработать свою программу.В C ++ нет ничего, что автоматически привело бы к лучшему модульному дизайну, все в руках программиста.

2) может быть достигнуто как в C, так и в C ++.Оба языка сократили объем данных.В C частная инкапсуляция осуществляется через несколько ужасный синтаксис с ключевым словом static для переменных области видимости файла.В C ++ это делается более элегантно с private / protected.

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

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

Казалось бы, весь аргумент OO не имеет большого значения, C ++ не являетсяогромное улучшение, когда дело доходит до ОО.Тогда что еще есть в C ++, что мне нужно во встроенной системе?Выделяется одна вещь: стандартизированный синтаксис встроенного ассемблера.Это, пожалуй, самое большое преимущество C ++ перед C для встраиваемых систем.

Кроме того, исключения, STL, шаблоны, RTTI, перегрузка овератора, перегрузка функций и т. Д., Все это более или менее бесполезные функции, которые можно использовать.жить без.

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

Answer 5

действительно ли есть заметная разница между C и C ++?

По моему опыту, есть большая разница в использовании оперативной памяти.

Например: IВ настоящее время я работаю над C ++ для ARM UC с 512 КБ FALSH и 64 КБ ОЗУ.Использование ОЗУ должно быть менее 30 КБ, но в два раза больше, потому что каждый констант заканчивается в ОЗУ.Это потому, что почти невозможно (по крайней мере с целями GCC и ARM) убедить компилятор оставить члены класса const во FLASH.Единственный способ добиться этого - использовать классы без конструктора, объявить все открытые члены const и использовать агрегированные списки инициализаторов.

Что еще хуже, C ++ не позволяет именовать элементы в списке инициализаторов, как выможно сделать простым языком C:

struct St {  int b;  int a[3];  };

static const struct St st_array[2] =
{
    [1] = { .a = {1,2,3,},  .b = 10, }, // deliberately disordered to
    [0] = { .b = 8,  .a = { 4,5,6,}, }, // illustate the value of names.
};

Все компиляторы C поместят эти константы в сегмент «константных данных» (во FLASH).

В C ++ вам придется сделать это:

class ClassA  // cannot have constructor or destructor
{
public:  // const data cannot be private for aggregate initialization
    const int b;
    const int a[3];
private:
    int priv_fn(int i);
public:
    int pub_fn();
};

static ClassA classA_array[2] = 
{   
    { 3, { 8, 9,10,}, },  // aggregate initialization 
    { 4, { 9,10,11,}, },  // better get the order right!!!
};

В зависимости от вашего компилятора, даже это может не гарантировать сохранения констант во FLASH.

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

Технический отчет (спасибо MSalters) подтверждает это:

7.1.2 Конструкторы и доступные для чтения объекты В общем случае const-объекты классов с конструкторами должны быть динамически инициализированы.Однако в некоторых случаях инициализация во время компиляции может быть выполнена, если статический анализ ...

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

Answer 6

Для "маленького следа", где я был бы обеспокоен, это раздувание кода. Если ваш код должен находиться на небольшом оборудовании, экземпляр класса шаблона

 std::vector<int>

имеет собственный набор инструкций, отдельный от

 std::vector<double>

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

С точки зрения производительности во время выполнения, я думаю, вам не о чем беспокоиться о . В некоторых случаях, таких как сортировка, C ++ превосходит C .