[Major 0]

Указатели на структуры - это практически когда возникает аналог this.

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

Полиморфизм - у вас есть абстрактный интерфейс, его наследуете и реализуете. Обработчику передаете указатель на абстрактный интерфейс.

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

 

По поводу ненужного в C и C++ спорить не хочется.

Во встроенных системах я старюсь избегать динамического перераспределения памяти. Если конкретно - память это не конкурентный ресурс.

Размеры областей памяти под все структуры расписаны на этапе компиляции. То есть если это будет std::list, то я приложу все усилия чтобы буфер под узлы был выделен при инициализации и не изменял свой размер при эксплуатации (сам list при этом динамический).

Мой подход к памяти упрощает анализ устойчивости системы на основе отчета компилятора.

 

Все написанное относится к АРМ (любым) с к компилятором Keil (ARM). Этому компилятору я верю, потому что много смотрел на код который он создает.

 

P.S.

На больших системах я себе ни в чем не отказываю. И boost и все остальное использую (и динам. память со смарт указателями).

 

[beaRTS 0]

Указатели на структуры - это практически когда возникает аналог this...

очень занимательно!!!

Выходит, разработчик-embedder в итоге, как ни крути, становится (должен стать/должен быть) полноценным программистом С++ (в смысле, которых специализированные кафедры выпускают) ??? таков путь развития?

Изменено 6 сентября, 2012 пользователем beaRTS

[Major 0]

Ну про пути я говорить не буду :) Есть мнения что C++ уже умер как перспективный ООП в широком смысле (и мне кажется есть основания).

 

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

1. Каждый певец в ООП поет по своему, чатос не понимая нот.

2. Документировать ООП сложнее (особенно когда широкая и глубокая родословная классов и интерфейсов)

3. В среде ГНУ не любят подчинения архитекторам (главным инженерам)

 

В своих работах надо это учитывать.

Читать ООП код написанный не по типовым шаблонам (Гамма и компания) и с размахом в наследовании очень тяжело.

Если кратко: тестовые наборы (test-case) и самодокументирование кода это обязанность программиста.

 

[haker_fox 61]

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

В моем случае ситуация следующая. Есть сеть. К этой сети могут быть подключены приборы. Количество не превышает 32. Но может быть 32 одинаковых прибора, а может быть 32 совершенно разных. А могут быть пять одинаковых, и десять - разных. Всем этим делом рулит "мастер", у которого программа скомпилирована раз и навсегда и не меняется. Я имею в виду системное ПО. О конфигурации приборов он или сам спрашивает, или ему услужливо "дают" список :rolleyes:

 

Для каждого прибора свой драйвер, за исключением одинаковых приборов.

 

Вот так и получается, что "поняв", чем ему придется управлять, он выделяет необходимое количество памяти для драйверов. Буду рад услышать как это можно сделать без использования кучи :rolleyes:

[beaRTS 0]

Есть мнения что C++ уже умер как перспективный ООП в широком смысле (и мне кажется есть основания).

чую - пахнет холиваром =)) :maniac: . но я даж спорить не будут - не компетентен))

 

Ну про пути я говорить не буду :)

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

Изменено 6 сентября, 2012 пользователем beaRTS

[Major 0]

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

 

У вас нет динамического распределения памяти, в классическом смысле.

Динамика это когда в рамках процесса (процессора) разные потоки исполнения в ходе работы запрашивают память и возвращают ее.

Время жизни объектов на куче неизвестно или сложно предсказуемо.

Когда функция запрашивает динамическую память есть вероятность отказа (исчерпание кучи).

Есть еще вариант когда многопроцессная система (есть ОСь) имеет менеджер памяти и память как ресурс раздается по приоритету. Такое приходится делать, ноя стараюсь избегать если имею достаточное количество памяти.

В моем опыте это упрощает запуск системы и позволяет снизить количество гонок за ресурсы. Если памяти мало, то конечно блочная куча.

 

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

У вас при старте есть память которую вы расписали по блокам, и потом на ней живете без возврата.

Или у вас сеть динамически может изменяться во времени?

 

Я не использую в эмбеддед постоянно создание и удаление объектов, как это делается на ПК (например динамические строки и stringbuilder).

И не использую не из-за времени исполнения, а из-за сложность обработки отказов в памяти и возможной фрагментации кучи (время жизни ВКЛ-ВЫКЛ от месяца до годов).

Я не использую исключения для возврата кода ошибки. Всегда проверяю код возврата.

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

На ПК все можно и надо делать наоборот (это может упростить архитектуру и повысить уровень обработки ошибок).

 

Если закрывать тему, то скажу что С++ надо использовать если вы понимаете, что начинаете его реализовать сами, при помощи семантики языка С. Компилятор Keil(ARM) дает качественный код С++.

 

 

 

 

[dxp 69]

чую - пахнет холиваром =)) :maniac: . но я даж спорить не будут - не компетентен))

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

[beaRTS 0]

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

да, было внутреннее ощущение, что скоро грани совсем размоются.

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

Изменено 6 сентября, 2012 пользователем beaRTS

[ReAl 0]

В моем случае ситуация следующая. Есть сеть. К этой сети могут быть подключены приборы. Количество не превышает 32. Но может быть 32 одинаковых прибора, а может быть 32 совершенно разных. А могут быть пять одинаковых, и десять - разных.

...

Буду рад услышать как это можно сделать без использования кучи :rolleyes:

 

Коротко: Искать по нашему форуму по словам placement new

 

Длиннее:

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

* Раз конфигурируется динамически, то так или иначе во время выполнения определяется тип — толи switch/case, толи виртуальными функциями. Пусть будет полиморфизм.

union {
   TDeviceTtype_1  device_type1;
   TDeviceTtype_2  device_type2;
   TDeviceTtype_3  device_type2;
} TAllDevices;

TAllDevices all_devices[max_devices];

Дальше используем пункт "коротко". Ну еще нужна переменная device_count, но она была бы нужна для массива указателей на TBaseDevice для случая выделения через new.

[alx2 0]

Да, Си++ иногда тянет за собой кучу ненужного и тяжелого

А что именно? Мне кроме исключений (которые можно отключить при компиляции) ничего в голову не приходит...

 

На AVR я с этим не сталкивался, но столкнулся на ARM7TDMI, когда захотел использовать динамическую память (оператор new). Как только использовал, так код с 40 кБ вырос до 300 кБ.

Пока чихаю на это, т.к. идет отладка. Но потом хочу прикрутить "легкую" реализацию менеджера памяти, любезно представленного уважаемым zltigo, и не менее любезно адаптированным к Си++ уважаемым Сергеем Борщем.

Сейчас провел "экспресс-тест". Весь код программы, использующей new и delete, составил меньше 9 килобайт (arm7tdmi). Почему у Вас new/delete потянули дополнительные 260 килобайт, ума не приложу. Тем более, что Вы не используете исключения... В любом случае, к языку C++ как таковому это не имеет отношения. Напротив, наличие в языке этих операторов (и, главное, возможность их перегружать по своему усмотрению) дает программисту возможность более тонко контролировать работу с памятью. В тривиальном случае new/delete могут работать через malloc/free и, таким образом, ничем не будут отличаться от аналогичного кода на языке C. Ничего "ненужного" эти операторы сами по себе не "тянут".

 

[sasamy 0]

Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет.

 

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

Изменено 7 сентября, 2012 пользователем sasamy

[dxp 69]

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

C - портабельный макроассемблер, с этим никто не спорит. Что ему замены нет да ещё и не будет - это сильное преувеличение - С++ с успехом заменяет С где угодно. Не стоит забывать, что С является подмножеством С++. Попробуйте доказательно оспорить тезис: "Где уместен С, там уместен и С++".

 

За моим "имхом" почти полтора десятка лет использования С++, из них десяток в embedded - у меня на глазах и с моим участием происходило проникновение С++ в эту область, поэтому я транслирую собственный опыт и опыт многих очень квалифицированных инженеров, некоторые из которых являются постоянными участниками и этого форума. Сегодня С++ - мэйнстрим в embedded, это факт. Не трогайте моё "имхо", я не буду трогать ваше. Лучше объективные аргументы приводите. Что С++ не заменяется С, с этим спорить не нужно, ибо зря, т.к. не заменяется. То, что немало упёртых линуксоидов во главе с Торвальдсом, который однажды 20 лет назад попробовал С++, находящийся в процессе роста и не имевший многих нынешних средств и но имевший много "детских болезней", не любят плюсы, это объективно характеризует их. Почти во всех случаях оные люди просто не знают С++ хоть сколько-нибудь глубоко (а главное - не желают знать, потому и не знают). Не принимайте на свой счёт, это общее наблюдение (не только моё) за много лет.

[halfdoom 0]

Совсем не давно, после длительного обсуждения с заказчиком (запад ЕС) платформы для прибора получили следующее на предложение об использовании плюсов:

 

Decision: accept a C-only code with minimal number of native assembler lines.

Reasoning: C++-code requires significant additional costs on verification staff, not an industry mainstream.

 

И все, либо проходите мимо, либо пишите на C.

[dxp 69]

А что это вот такое:

C++-code requires significant additional costs on verification staff

 

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

[Major 0]

Еще раз вмешаюсь.

C++ это язык, возможности которого шире чем C.

Я уже привел доводы почему в ГНУ используют в основном С,реализуя элементы С++.

Мощь С++ в ООП (ООД). Без ООП С++ это всего лишь расширение С. ООП это годы тренировок и учебы.

При этом делать попытки ООП на чистом С, реализуя каждый раз велосипед, это торможение в развитии.

 

Многие лекарства ядовиты в дозах больше чем 100мгр. Но это не означает что их не надо изготовлять и пользоваться. Горчичник я могу сам сделать, но для антибиотика нужны фармацевты и провизоры.