Объектная ориентация плохо для встроенных систем, и почему? [закрытый]
8 ответов
Хотя я не уверен, что это ответ на ваш вопрос, я могу кратко описать причины, по которым исходный код моей предыдущей компании был на чистом C.
Прежде всего, стоит кратко описать ситуацию:
- мы хотели написать большой объем "основного" кода, который был бы хорошо переносим на большое количество встроенных систем ARM (в основном, мобильные телефоны среднего класса; как смартфоны, так и телефоны, работающие под управлением RTOS разных лет)
- платформы, как правило, имели работоспособный компилятор языка Си, хотя некоторые, например, не поддерживали "двойки" с плавающей точкой.
- в некоторых случаях платформа имела разумную реализацию стандартной библиотеки, но во многих случаях ее не было.
- компилятор C++ не был доступен на большинстве платформ, а там, где он был доступен, поддержка стандартной библиотеки C++, STL или исключений была весьма различной.
- отладчики часто были недоступны (последовательный порт, на который можно было отправить отладочные printfs, считался роскошью)
- у нас всегда был доступ к разумному объему памяти, но часто не было разумной реализации malloc()
Учитывая это, мы работали полностью на C, и даже тогда только с ограниченным набором C 89. Полученный код был очень переносимым. Однако мы часто использовали объектно-ориентированные концепции.
В наши дни "встроенный" - это очень широкое определение. Оно охватывает все - от 8-битных микропроцессоров без оперативной памяти и компиляторов языка C до, по сути, высококлассных ПК (хотя и не работающих под управлением Microsoft Windows) - я не знаю, где в этом диапазоне находится ваш проект/компания.
Ничего из «объектно-ориентированного» не является плохим для встраиваемых систем. ОО - это просто способ мышления о программном обеспечении.
Что плохо для встроенных систем, так это то, что они, как правило, имеют менее сложные отладчики, а C ++ делает много сумасшедших вещей «за вашей спиной», так сказать. Эти фрагменты кода, к которому трудно получить доступ, сведут вас с ума.
Объектно-ориентированный дизайн сам по себе неплох. Ответ кроется в вашей цитате. Вы хотите сделать свой код максимально легким и эффективным, особенно во встраиваемых системах реального времени. Вещи, упомянутые в вашей цитате (объекты, разделение, распределение динамической памяти), относительно тяжеловесны и обычно могут быть заменены более простыми альтернативами (например, с использованием битовых манипуляций для приблизительного деления, выделения памяти в стеке или статических пулов) для улучшения производительность в критических по времени системах.
Почему вы говорите, что C ++ - это Объектно-ориентированный? C ++ - это мультипарадигма, и не все функции, предоставляемые C ++, полезны для рынка встраиваемых систем из-за накладных расходов. (Так что ... Просто не используйте эти функции! Проблема решена!)
Программирование - это всегда использование правильного инструмента для работы. Не существует однозначных ответов, и это особенно верно в мире встраиваемых систем. Если вы хотите стать квалифицированным специалистом в области разработки встраиваемых систем, вы будете так же хорошо знакомы с C, как и с C++.
Принимая вашу цитату за чистую монету, динамическое выделение памяти - это совершенно отдельная концепция от объектно-ориентированного проектирования программного обеспечения, так что это откровенная ложь. Вы можете иметь объектно-ориентированный дизайн и не использовать динамическое распределение памяти.
Фактически, вы можете выполнять объектно-ориентированный объект в C до некоторой степени (это то, что делает ядро Linux). Настоящая настоящая причина того, что многие разработчики встраиваемых систем не любят C ++, заключается в том, что он очень сложен и на нем трудно написать прямой и предсказуемый код. У Линуса недавно была хорошая напыщенная речь о том, почему ему не нравится C ++ (он лучше и более аргументирован, чем его старый , я обещаю). Вероятно, большинство людей просто не очень хорошо это формулируют.
C ++ был разработан с философией не платите за то, что не используете . Так что, кроме отсутствия хороших встроенных компиляторов, реальной причины нет.
Возможно, CFront мог бы скомпилировать C ++ в C, который имеет несметное количество компиляторов ...
Редактировать: Компилятор Comeau преобразует C ++ в простой C, поэтому аргумент без компилятора не держать.
Как отмечали другие, «встроенный» включает в себя широкий и разнообразный набор аппаратных / программных опций. Но ...
Цитата, которую вы дадите, вызовет дрожь в отношении встроенных типов микроконтроллеров. Динамическое размещение - это недопустимо, если у вас есть ошибка, вы непредсказуемо вылетаете из строя. Деления сильно не приветствуются, поскольку они занимают вечно времени выполнения. Объекты не приветствуются только постольку, поскольку они имеют тенденцию таскать с собой множество «вещей», все эти «вещи» занимают место, а у микроконтроллеров его нет.
Я считаю встраиваемые проекты небольшими и конкретными, вы не особо беспокоитесь о расширяемости или переносимости. Вы пишете чистый код на C, который надежно выполняет только то, что вы хотите, чтобы ваше устройство выполняло. Вы выбираете одно семейство микросхем, чтобы вы могли перемещать свой (почти одинаковый) код среди различных аппаратных опций с небольшими настройками порта, который вы пишете, или инициализацией предохранителей конфигурации.
Итак, вам не нужно определять
- 4-колесный транспорт
- Автомобиль
- Toyota
, поскольку вы работаете только с Toyota. А разница в ускорении между Camry и Corolla сохраняется в виде констант в регистре.