Является ли объектная ориентация плохим для встроенных систем и почему?

Ответ 1

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

Во-первых, стоит подвести итог ситуации:

• мы хотели написать большой объем "основного" кода, который был бы очень переносимым в большом количестве встроенных систем ARM (в основном мобильных телефонов среднего класса, как смартфонов, так и тех, которые работают с ОСРВ разного возраста).
• на платформах обычно был работоспособный компилятор C, хотя некоторые, например, не поддерживали "двойные" точки с плавающей запятой.
• В некоторых случаях платформа имела разумную реализацию стандартной библиотеки, но во многих случаях этого не делала.
• Компилятор С++ не был доступен на большинстве платформ, и там, где была доступна поддержка стандартной библиотеки С++, STL или исключения были очень переменными.
• отладчики часто не были доступны (последовательный порт, по которому вы могли отправлять отладочные printfs, считался роскошью)
• мы всегда имели доступ к разумному объему памяти, но часто не к разумной реализации malloc()

Учитывая, что мы полностью работали на C и даже тогда только ограниченный набор C 89. Полученный код был очень портативным. Мы часто использовали объектно-ориентированные концепции.

В наши дни "встроенный" - очень широкое определение. Он охватывает все, начиная с 8-битных микропроцессоров без компиляторов RAM или C до того, что по существу является высокопроизводительным ПК (хотя и не работает под управлением Microsoft Windows). Я не знаю, где ваш проект/компания находится в этом диапазоне.

Ответ 2

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

Фактически, вы можете делать OO в C до такой степени (что делает ядро Linux). Реальная причина, по которой многим разработчикам встраиваемых систем не нравится C++, заключается в том, что он очень сложный, и в него трудно писать прямой и предсказуемый код. У Линуса есть хорошая недавняя напыщенная речь о том, почему ему не нравится C++ (я обещаю, что он лучше и более аргументирован, чем его старый). Вероятно, большинство людей просто не формулируют это очень хорошо.

Ответ 3

Что заставляет вас сказать, что С++ объектно-ориентированный? С++ - это multiparadigm, и не все возможности, предоставляемые С++, полезны для встроенного рынка из-за их накладных расходов. (Так что... Просто не используйте эти функции! Проблема решена!)

Ответ 4

Object Oriented отлично подходит для встроенных систем. В нем много внимания уделяется инкапсуляции, скрытию данных и совместному использованию кода. Можно иметь объектно-ориентированные встроенные системы без разделения или динамической памяти.

Разделение и динамическое распределение памяти являются врагами встроенных систем, независимо от объектно-ориентированного, ориентированного на данные или процедурного программирования. Эти концепции могут использоваться или не использоваться при реализации объектно-ориентированных конструкций.

Object Oriented позволяет классу UART передавать экземпляры объектов Message, не зная содержимого объектов Message. Сообщение может быть базовым классом и иметь несколько классов потомков.

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

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

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

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

Язык C выполняет функции указателей на функции. Языки С++ предоставляют средства для объектов функций (указатели функций с атрибутами).

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

Ответ 5

Ничего о "объектно-ориентированном" плохо для встроенных систем. OO - это всего лишь способ мышления о программном обеспечении.

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

Ответ 6

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

Ответ 7

С++ был разработан с философией , не платите за то, что вы не используете. Поэтому, кроме отсутствия хороших встроенных компиляторов, нет никакой реальной причины.

Возможно, CFront мог бы скомпилировать С++ в C, который содержит множество компиляторов...

Изменить: компилятор Comeau преобразует С++ в обычный C, поэтому аргумент no-compiler не выполняется.

Ответ 8

Как отмечали другие, "встроенный" охватывает широкий и разнообразный набор аппаратных/программных опций. Но...

Цитата, которую вы даете, даст водителю встроенные типы микроконтроллеров. Динамическое распределение - это не-нет, если у вас есть ошибка, вы можете непредвиденным образом разрушить систему. Разделения в значительной степени обескуражены, так как они навсегда остаются во время исполнения. Объекты только обескуражены, поскольку они, как правило, несут много "вещей" вокруг них, все, что "материал" занимает место, а микроконтроллеры не имеют.

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

Итак, вам не нужно определять

• 4-х колесный транспорт
• Автомобиль
• Toyota​​li >

Так как вы работаете только с Toyotas. И разница в ускорениях между Camry и Corolla сохраняется как константы в регистре.

Ответ 9

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

Ответ 10

Как было сказано выше, это то, что объектно-ориентированное/malloc/math делает за вашей спиной, что несет штраф - как в размере кода, так и в циклах ЦП, которые обычно не хватает в встроенных.

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

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

Ответ 11

Во-первых, давайте разберемся с этим:

поэтому мы предпочитаем, чтобы люди не использовали метод split..., malloc... или другую объектно-ориентированную практику, которая влечет за собой большие штрафы.

Division и malloc не являются уникальными для объектно-ориентированного программирования, они также присутствуют в процедурных языках (и, по-видимому, функциональных и любых других парадигм, о которых вы можете подумать).

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

На главную тему "Является ли ориентация объекта плохой для встроенных систем?".

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

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

Однако, если вы придерживаетесь "пуританского" взгляда на ООП и настаиваете на включении наследования и полиморфизма, тогда ответ "да, это плохо". Наследование, возможно, не так важно (в зависимости от языка), но полиморфизм с помощью методов virtual является определенным стимулом для памяти. Функции virtual обычно реализуются путем поддержки vtable (таблицы виртуальных методов), в которой хранятся указатели на правильные функции, и каждый объект должен хранить указатель на свою vtable, чтобы включить динамическую диспетчеризацию (процесс вызова виртуальных функций) для работать должным образом. Существуют обстоятельства, при которых наследование может использовать больше памяти, чем решения, которые не требуют наследования - обычно при сравнении наследования с композицией композиция иногда использует меньше памяти.

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

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