|
|
  |
Embedded C++, Кто какие библиотеки использует? |
|
|
|
Sep 6 2012, 02:19
|
Местный
  
Группа: Участник
Сообщений: 211
Регистрация: 27-12-11
Из: Челябинск
Пользователь №: 69 111

|
Цитата(Major @ Sep 6 2012, 05:37)  Указатели на структуры - это практически когда возникает аналог this... очень занимательно!!! Выходит, разработчик-embedder в итоге, как ни крути, становится (должен стать/должен быть) полноценным программистом С++ (в смысле, которых специализированные кафедры выпускают) ??? таков путь развития?
Сообщение отредактировал beaRTS - Sep 6 2012, 02:41
--------------------
"Об уме человека вернее судить по его вопросам, нежели по его ответам" (с)
|
|
|
|
|
Sep 6 2012, 03:09
|
Знающий
   
Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375

|
Ну про пути я говорить не буду  Есть мнения что C++ уже умер как перспективный ООП в широком смысле (и мне кажется есть основания). Хочу отметить что большинство GNU проектов пишутся на C, и реализуют каждый раз C++. Причины: 1. Каждый певец в ООП поет по своему, чатос не понимая нот. 2. Документировать ООП сложнее (особенно когда широкая и глубокая родословная классов и интерфейсов) 3. В среде ГНУ не любят подчинения архитекторам (главным инженерам) В своих работах надо это учитывать. Читать ООП код написанный не по типовым шаблонам (Гамма и компания) и с размахом в наследовании очень тяжело. Если кратко: тестовые наборы (test-case) и самодокументирование кода это обязанность программиста.
|
|
|
|
|
Sep 6 2012, 03:25
|

Познающий...
     
Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125

|
QUOTE (Major @ Sep 6 2012, 09:37)  Во встроенных системах я старюсь избегать динамического перераспределения памяти. В моем случае ситуация следующая. Есть сеть. К этой сети могут быть подключены приборы. Количество не превышает 32. Но может быть 32 одинаковых прибора, а может быть 32 совершенно разных. А могут быть пять одинаковых, и десять - разных. Всем этим делом рулит "мастер", у которого программа скомпилирована раз и навсегда и не меняется. Я имею в виду системное ПО. О конфигурации приборов он или сам спрашивает, или ему услужливо "дают" список Для каждого прибора свой драйвер, за исключением одинаковых приборов. Вот так и получается, что "поняв", чем ему придется управлять, он выделяет необходимое количество памяти для драйверов. Буду рад услышать как это можно сделать без использования кучи
--------------------
Выбор.
|
|
|
|
|
Sep 6 2012, 04:23
|
Местный
  
Группа: Участник
Сообщений: 211
Регистрация: 27-12-11
Из: Челябинск
Пользователь №: 69 111

|
Цитата(Major @ Sep 6 2012, 07:09)  Есть мнения что C++ уже умер как перспективный ООП в широком смысле (и мне кажется есть основания). чую - пахнет холиваром =))  . но я даж спорить не будут - не компетентен)) Цитата(Major @ Sep 6 2012, 07:09)  Ну про пути я говорить не буду  а почему? все так запутанно? или как у Кастанеды: "Каждый идет своим путем. Но все дороги всё равно ведут в никуда. (прим. к смерти) Весь смысл в самой дороге, как по ней идти, дорога должна быть "с сердцем": если идешь с удовольствием, значит, это твоя дорога. Если тебе плохо – в любой момент можешь сойти с нее, как бы далеко ни зашел. И это будет правильно"
Сообщение отредактировал beaRTS - Sep 6 2012, 05:04
--------------------
"Об уме человека вернее судить по его вопросам, нежели по его ответам" (с)
|
|
|
|
|
Sep 6 2012, 05:10
|
Знающий
   
Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375

|
Цитата Вот так и получается, что "поняв", чем ему придется управлять, он выделяет необходимое количество памяти для драйверов. Буду рад услышать как это можно сделать без использования кучи У вас нет динамического распределения памяти, в классическом смысле. Динамика это когда в рамках процесса (процессора) разные потоки исполнения в ходе работы запрашивают память и возвращают ее. Время жизни объектов на куче неизвестно или сложно предсказуемо. Когда функция запрашивает динамическую память есть вероятность отказа (исчерпание кучи). Есть еще вариант когда многопроцессная система (есть ОСь) имеет менеджер памяти и память как ресурс раздается по приоритету. Такое приходится делать, ноя стараюсь избегать если имею достаточное количество памяти. В моем опыте это упрощает запуск системы и позволяет снизить количество гонок за ресурсы. Если памяти мало, то конечно блочная куча. В вашем случае точно известно (на этапе компиляции) сколько необходимо памяти для каждого драйвера. Память раздает фабрика, создающая экземпляр драйвера, в эксклюзивном режиме. Вы заранее можете рассчитать возможность отказа в обслуживании устройства. У вас при старте есть память которую вы расписали по блокам, и потом на ней живете без возврата. Или у вас сеть динамически может изменяться во времени? Я не использую в эмбеддед постоянно создание и удаление объектов, как это делается на ПК (например динамические строки и stringbuilder). И не использую не из-за времени исполнения, а из-за сложность обработки отказов в памяти и возможной фрагментации кучи (время жизни ВКЛ-ВЫКЛ от месяца до годов). Я не использую исключения для возврата кода ошибки. Всегда проверяю код возврата. Но использую исключения когда надо пробросить информацию об отказе на самый верх, где будет принято решение о перезагрузке или еще что-то. На ПК все можно и надо делать наоборот (это может упростить архитектуру и повысить уровень обработки ошибок). Если закрывать тему, то скажу что С++ надо использовать если вы понимаете, что начинаете его реализовать сами, при помощи семантики языка С. Компилятор Keil(ARM) дает качественный код С++.
|
|
|
|
|
Sep 6 2012, 06:59
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
QUOTE (beaRTS @ Sep 6 2012, 11:23)  чую - пахнет холиваром =))  . но я даж спорить не будут - не компетентен)) Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет. Просто по мере развития элементной базы и аппаратных платформ всё больше появляется возможностей для использования более высокоуровневых средств, включая языки программирования, библиотеки, фреймворки. Не редкость уже случаи, когда на embedded платформах используют виртуальные машины и скриптовые движки (жаба, шарп, питон и т.п.), в то время как и на настольных машинах есть место для низкоуровневых языков C/C++, когда надо выжимать производительность.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Sep 6 2012, 07:16
|
Местный
  
Группа: Участник
Сообщений: 211
Регистрация: 27-12-11
Из: Челябинск
Пользователь №: 69 111

|
Цитата(dxp @ Sep 6 2012, 10:59)  Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет. Просто по мере развития элементной базы и аппаратных платформ всё больше появляется возможностей для использования более высокоуровневых средств, включая языки программирования, библиотеки, фреймворки. Не редкость уже случаи, когда на embedded платформах используют виртуальные машины и скриптовые движки (жаба, шарп, питон и т.п.), в то время как и на настольных машинах есть место для низкоуровневых языков C/C++, когда надо выжимать производительность. да, было внутреннее ощущение, что скоро грани совсем размоются. Я тут с Питоном познакомился недавно (поверхностно) - понравилось. Его обычно как в embedded используют: пишутся скрипты-тесты, генерирующие входные данные для железяки и программы в ней, написанной, например, на С++ ??? а потом эти тесты анализируют то, что на выходе получено, и говорят "все ок" или "давай, до свиданья"  ?
Сообщение отредактировал beaRTS - Sep 6 2012, 07:17
--------------------
"Об уме человека вернее судить по его вопросам, нежели по его ответам" (с)
|
|
|
|
|
Sep 6 2012, 07:35
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(haker_fox @ Sep 6 2012, 06:25)  В моем случае ситуация следующая. Есть сеть. К этой сети могут быть подключены приборы. Количество не превышает 32. Но может быть 32 одинаковых прибора, а может быть 32 совершенно разных. А могут быть пять одинаковых, и десять - разных. ... Буду рад услышать как это можно сделать без использования кучи  Коротко: Искать по нашему форуму по словам 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.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Sep 7 2012, 05:16
|

Местный
  
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091

|
Цитата(haker_fox @ Sep 6 2012, 04:51)  Да, Си++ иногда тянет за собой кучу ненужного и тяжелого А что именно? Мне кроме исключений (которые можно отключить при компиляции) ничего в голову не приходит... Цитата(haker_fox @ Sep 6 2012, 04:51)  На AVR я с этим не сталкивался, но столкнулся на ARM7TDMI, когда захотел использовать динамическую память (оператор new). Как только использовал, так код с 40 кБ вырос до 300 кБ. Пока чихаю на это, т.к. идет отладка. Но потом хочу прикрутить "легкую" реализацию менеджера памяти, любезно представленного уважаемым zltigo, и не менее любезно адаптированным к Си++ уважаемым Сергеем Борщем. Сейчас провел "экспресс-тест". Весь код программы, использующей new и delete, составил меньше 9 килобайт (arm7tdmi). Почему у Вас new/delete потянули дополнительные 260 килобайт, ума не приложу. Тем более, что Вы не используете исключения... В любом случае, к языку C++ как таковому это не имеет отношения. Напротив, наличие в языке этих операторов (и, главное, возможность их перегружать по своему усмотрению) дает программисту возможность более тонко контролировать работу с памятью. В тривиальном случае new/delete могут работать через malloc/free и, таким образом, ничем не будут отличаться от аналогичного кода на языке C. Ничего "ненужного" эти операторы сами по себе не "тянут".
--------------------
Всего наилучшего, Alex Mogilnikov
|
|
|
|
|
Sep 7 2012, 17:41
|
Знающий
   
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858

|
Цитата(dxp @ Sep 6 2012, 10:59)  Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет. Для чистого С как кроссплатформенного ассемблера замены нет и не будет, а вот С++ - это ваше имхо разумеется, очень сильно расходящееся с реальностью. Чтобы не разводить холливар - чем больше ЯП вы владеете тем лучше, но важней изучить парадигмы программирования а не реализации их в конкретных ЯП, в конце концов важнее знание предметной области, а ЯП как инструмент вторичен.
Сообщение отредактировал sasamy - Sep 7 2012, 21:02
|
|
|
|
|
Sep 8 2012, 02:49
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
QUOTE (sasamy @ Sep 8 2012, 00:41)  Для чистого С как кроссплатформенного ассемблера замены нет и не будет, а вот С++ - это ваше имхо разумеется, очень сильно расходящееся с реальностью. Чтобы не разводить холливар - чем больше ЯП вы владеете тем лучше, но важней изучить парадигмы программирования а не реализации их в конкретных ЯП, в конце концов важнее знание предметной области, а ЯП как инструмент вторичен. C - портабельный макроассемблер, с этим никто не спорит. Что ему замены нет да ещё и не будет - это сильное преувеличение - С++ с успехом заменяет С где угодно. Не стоит забывать, что С является подмножеством С++. Попробуйте доказательно оспорить тезис: "Где уместен С, там уместен и С++". За моим "имхом" почти полтора десятка лет использования С++, из них десяток в embedded - у меня на глазах и с моим участием происходило проникновение С++ в эту область, поэтому я транслирую собственный опыт и опыт многих очень квалифицированных инженеров, некоторые из которых являются постоянными участниками и этого форума. Сегодня С++ - мэйнстрим в embedded, это факт. Не трогайте моё "имхо", я не буду трогать ваше. Лучше объективные аргументы приводите. Что С++ не заменяется С, с этим спорить не нужно, ибо зря, т.к. не заменяется. То, что немало упёртых линуксоидов во главе с Торвальдсом, который однажды 20 лет назад попробовал С++, находящийся в процессе роста и не имевший многих нынешних средств и но имевший много "детских болезней", не любят плюсы, это объективно характеризует их. Почти во всех случаях оные люди просто не знают С++ хоть сколько-нибудь глубоко (а главное - не желают знать, потому и не знают). Не принимайте на свой счёт, это общее наблюдение (не только моё) за много лет.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Sep 8 2012, 03:50
|

Профессионал
    
Группа: Свой
Сообщений: 1 003
Регистрация: 20-01-05
Пользователь №: 2 072

|
Совсем не давно, после длительного обсуждения с заказчиком (запад ЕС) платформы для прибора получили следующее на предложение об использовании плюс ов: Цитата 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.
|
|
|
|
|
  |
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|