Easyelectronics.ru

Электроника для всех
Текущее время: 23 окт 2019, 23:31

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/10pcs (Любой цвет!)
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 318 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13  След.
Автор Сообщение
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 09 ноя 2018, 19:08 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
Правильно ли понимаю - у segger своя реализация newlib?

Цитата:

GCC в настоящее время является конкурентным выбором компилятора для встроенных систем. Большинство наборов инструментов, использующих GCC, также используют newlib, newlib-nano или glibc. К сожалению, они имеют значительные недостатки в отношении профессиональных библиотек времени выполнения для встроенных систем.

Здесь emLib-C вступает в игру.

emLib-C просто заменяет newlib, newlib-nano и glibc, что превращает любую инструментальную цепочку на основе GCC в профессиональный выбор. emLib-C используется в Embedded Studio и доказал свою ценность в течение многих лет.



Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 10 ноя 2018, 13:52 
Старожил

Зарегистрирован: 08 авг 2013, 09:43
Сообщения: 2284
Pingvin писал(а):
У меня оператор new переопределён

Тогда не понимаю какие могут быть вопросы к new и c++?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 10 ноя 2018, 14:47 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
NStorm писал(а):
Pingvin писал(а):
У меня оператор new переопределён

Тогда не понимаю какие могут быть вопросы к new и c++?

Вопрос в том - отслеживает ли корректно системный malloc() (получается - segger-овский) объём свободной памяти?
Придется пробовать выделить явно больший кусок памяти, чем размер кучи и посмотреть..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 29 дек 2018, 10:30 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
Если кто захочет использовать STL в SEGGER, краткая инструкция

1. Устанавливаем STL
Tools->Package Manager

находим
STLport Library Package
Кликаем по нему, чтобы в поле Action появилось install
В низу жмем кнопку "next"

2. После установки прописываем пути до библиотеки
В дереве проектов выбираем наш проект, кликаем правой кнопкой -> Options

Code->Preprocessor->User include Directjries
Добавляем новый путь (в самый верх списка)
$(ProjectDir)/include/stlport

3. Активируем библиотеку
Code->Libraries->STLport library выбыраем Yes

Все - должно заработать!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 02 янв 2019, 09:01 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
C eclipse и ARM plugin все оказалось ещё проще!
Создал проект, и там newlib подключен по умолчанию и STL работает "из коробки".
Знающие люди говорят, что это более кашерный STL.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 янв 2019, 17:41 
Старожил
Аватара пользователя

Зарегистрирован: 19 фев 2015, 17:37
Сообщения: 1524
Откуда: void
А компилятор gcc умеет в умные указатели для Cortex-M платформ? Да, я хочу использовать динамическую память на МК и смотрю в сторону С++.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 14 янв 2019, 12:41 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 370
Faberge писал(а):
А компилятор gcc умеет в умные указатели для Cortex-M платформ? Да, я хочу использовать динамическую память на МК и смотрю в сторону С++.


Стесняюсь спросить, но все же, будучи из деревни, спрошу: а для каких нужд может пригодиться на МК динамическая память? Нет, я, конечно, могу предположить варианты, даже у самого изредка шальная мысль в задачах для DSP проскакивает, но разве не проще ли тогда статически выделить при ините массив и сделать свои функции для выделения памяти уже в этом массиве? Хороший пример - zone memory в думе и первокваке, в открытом виде на гитхабе есть.

https://github.com/id-Software/Quake/bl ... ent/zone.c


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 14 янв 2019, 19:42 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 851
Faberge писал(а):
А компилятор gcc умеет в умные указатели для Cortex-M платформ? Да, я хочу использовать динамическую память на МК и смотрю в сторону С++.

Это зависит от используемой стандартной библиотеки.
В newlib поддержка shared_ptr (А значит и всего семейства умных указателей) заявлена.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 15 янв 2019, 06:47 
Старожил
Аватара пользователя

Зарегистрирован: 28 фев 2011, 19:28
Сообщения: 3609
Откуда: Белгород РФ
sdv_cyborg писал(а):
Стесняюсь спросить, но все же, будучи из деревни, спрошу: а для каких нужд может пригодиться на МК динамическая память?


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 09:04 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
Расскажу о своих граблях...
Начал докладывать завершающий кирпичик в свою прошивку на плюсах, а именно реализовывать работу с радиомодулем.
Разумеется, для хранения пакетов (принятых и ожидающих отправку) решил использовать стандартные контейнеры STL.
Для начала взял std::list.
А как недавно узнал - list вызывает new/delete при любом добавлении или удалении элемента - не самый удачный выбор, как теперь я понимаю.
И таки да - вот они, грабли!
Прошивка стала вылетать.
Ну думаю - началось то, о чём предупреждали мудрейшие аксакалы форума - вот она утечка памяти и все прочие прелести при работе с динамическим выделением памяти.
Хотя я new/delete переопределял для потокобезопасности.
Решил избавиться от частого вызова new/delete и заменил контейнеры на std::vector, причем сразу в конструкторе класса зарезервировал место в куче для них используя метод reserve(...)

new/delete перестали вызываться, но проблема не ушла, а даже вылетать стало сразу.
При более тщательном анализе проблемы выявил её источник - это функция удаления пакета из очереди ожидания.

Код:
void remove_waiting_package(PackageId packageID){
   for (auto it = m_waitingPackages.begin(); it != m_waitingPackages.end(); it++)
      {
         if ((*it).package.details.packageId == packageID){
            m_waitingPackages.erase(it);
         }
   }

}



Детская ошибка - кто найдет? :-)

В общем - исправил функцию и стабильно заработали как вариант с vector так и вариант c list.
Так что дело было не в динамическом выделении памяти.

Но дабы не искушать судьбу, оставлю все таки vector.
Ему место заранее зарезервировал и он кучу больше не дергает, если не превышать максимальное количество хранимых элементов.

Шишки тоже нужны, это опыт.
В целом интересно, зря вы плюсов боитесь.
Я уже обратно на Си не хочу...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 10:27 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Цитата:
Because vectors use an array as their underlying storage, erasing elements in positions other than the vector end causes the container to relocate all the elements after the segment erased to their new positions.

оспидя...
на критике этих с++ граблей, и именно в vector, построен начальный курс молодого Rust подована

Цитата:
Ему место заранее зарезервировал и он кучу больше не дергает

какая наивность...

Цитата:
Я уже обратно на Си не хочу.

а представляешь, есть такие люди которые не то что на С.... на С++ уже не хотят.


поверь.
то, с чем ты столкнулся - это просто песчинка, по сравнению с тем, с чем тебе ещё предстоит столкнуться в С++

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 10:30 
Старожил

Зарегистрирован: 10 фев 2016, 19:55
Сообщения: 298
Что касается -- "кто найдёт?"
Не являюсь экспертом в С++ и STL, но как видится проблема будет возникать, если будет выполняться удаление последнего элемента из коллекции. После удаления последнего элемента не сработает условие:
Код:
it != m_waitingPackages.end();

и цикл продолжит своё выполнение, начав совершать гнустные действия над "чужой" памятью.
Помогло бы условие:
Код:
it < m_waitingPackages.end();

но вроде как в STL-ных итераторах такого нет, хотя можно покопать в сторону перегрузки операторов.
Что касается остального:
Pingvin писал(а):
Ну думаю - началось то, о чём предупреждали мудрейшие аксакалы форума - вот она утечка памяти и все прочие прелести при работе с динамическим выделением памяти.

За утечкой памяти должен следить программист. А вот с фрагментацией памяти бороться не так просто -- нужно не просто вовремя освобождать память, нужно ещё следить за тем, чтобы выделение и освобождение памяти для разных переменных делалось в правильном порядке. А это почти не разрешимая задача. И вторая проблема динамического выделения -- это повышенный расход оперативки. Таблицу выделенных участков памяти надо где-то хранить. И чем больше участков памяти выделяется, тем "толще" становиться эта таблица. А когда оперативы и так "кот наплакал" начинаются проблемы.
Pingvin писал(а):
В целом интересно, зря вы плюсов боитесь.
Я уже обратно на Си не хочу...

Использование "плюсов" для маленьких МК типа ATmega328, STM32, имеются в виду с оперативой 2-8 кБ и flash 8-64 кБ, просто избыточно. А с компилятором GCC и AVR-ми ещё и словите проблем, если будете пользоваться виртуальными функциями. Не знаю как с STM32 дела обстоят, но в AVR-ках таблица виртуальных функций за каким-то хреном копируется в оперативу, что на заре освоения этих МК мне доставило не мало проблем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 10:34 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Цитата:
За утечку памяти должен следить программист

если прога уровня hello world - то да.

чуть больше, сложнее - и без smart pointers уже никак.

_________________
unirail.org


Последний раз редактировалось cheblin 13 сен 2019, 10:58, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 10:39 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Цитата:
азумеется, для хранения пакетов (принятых и ожидающих отправку) решил использовать стандартные контейнеры STL.


это ошибка архитектуры. проходили, ибо не всё так однозначно.

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

пакеты, обработка которых может быть рессурсоемкой, идут в очередь на обработку.
теперь про очередь приёма... она не должна быть одной, в которую кладутся все приятые пакеты. это ощибка

почему:

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

в BlackBox функция диспетчера выглядит так

Код:
static Meta const * dispatch(Receiver * receiver, size_t id, Pack * pack)
                {
                    CHANNEL * channel = CHANNEL::from(receiver);
                    using namespace org::unirail;
                    switch(id)
                    {
                        default:
                            return nullptr;
                        case 1:
                            return pack ? channel->on_EmptyPack2(), nullptr : &MetaInfo::meta1;
                        case 2:
                            return pack ? channel->on_VarPack(pack), nullptr : &MetaInfo::meta2;
                        case 3:
                            return pack ? channel->on_IntegeR(pack), nullptr : &MetaInfo::meta3;
                        case 4:
                            return pack ? channel->on_v3List(pack), nullptr : &MetaInfo::meta4;
                        case 5:
                            return pack ? channel->on_v3List_arr(pack), nullptr : &MetaInfo::meta5;
                        case 6:
                            return pack ? channel->on_Vector3(pack), nullptr : &MetaInfo::meta6;
                        case 7:
                            return pack ? channel->on_Vector3_arr(pack), nullptr : &MetaInfo::meta7;
                        case 8:
                            return pack ? channel->on_new_Embedded(pack), nullptr : &MetaInfo::meta8;
                        case 9:
                            return pack ? channel->on_UseVarPack(pack), nullptr : &MetaInfo::meta9;
                        case 10:
                            return pack ? channel->on_Person(pack), nullptr : &MetaInfo::meta10;
                        case 11:
                            return pack ? channel->on_largeString(pack), nullptr : &MetaInfo::meta11;
                        case 4677:
                            return pack ? channel->on_PING33(pack), nullptr : &MetaInfo::meta4677;
                    }
                }

on_v3List(pack)
on_VarPack(pack)

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

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 10:58 
Старожил

Зарегистрирован: 10 фев 2016, 19:55
Сообщения: 298
cheblin писал(а):
Цитата:
Because vectors use an array as their underlying storage, erasing elements in positions other than the vector end causes the container to relocate all the elements after the segment erased to their new positions.

оспидя...
на критике этих с++ граблей, и именно в vector, построен начальный курс молодого Rust подована

А какое отношение выделение новой памяти под хранение данных вектора имеет отношение к ошибке, озвученной 'Pingvin'?
cheblin писал(а):
чуть больше, сложнее - и уже без smart pointers уже никак

А это и есть один из механизмов контроля программистом.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:00 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
У меня при приеме пакета он сразу проверяется на уникальность (что раньше уже не был принят) и уникальные пакеты кладутся в очередь и обрабатываются в отдельном потоке.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:02 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
Netzschlange писал(а):
Что касается -- "кто найдёт?"
Не являюсь экспертом в С++ и STL, но как видится проблема будет возникать, если будет выполняться удаление последнего элемента из коллекции. После удаления последнего элемента не сработает условие:
Код:
it != m_waitingPackages.end();



Верно!
Обращение к несуществующему элементу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:03 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
cheblin писал(а):
Цитата:
Because vectors use an array as their underlying storage, erasing elements in positions other than the vector end causes the container to relocate all the elements after the segment erased to their new positions.

оспидя...
на критике этих с++ граблей, и именно в vector, построен начальный курс молодого Rust подована

Цитата:
Ему место заранее зарезервировал и он кучу больше не дергает

какая наивность...



Не наивность, а знание предмета.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:05 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Netzschlange писал(а):
А какое отношение выделение новой памяти под хранение данных вектора имеет отношение к ошибке, озвученной 'Pingvin'?
cheblin писал(а):
чуть больше, сложнее - и уже без smart pointers уже никак

А это и есть один из механизмов контроля программистом.

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

Цитата:
А это и есть один из механизмов контроля программистом.

тогда и GC - один из механизмов контроля памяти программистом. ОК

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:07 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Цитата:
Ему место заранее зарезервировал и он кучу больше не дергает

reallocation это и есть то самое дерганье кучи.

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:07 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
На Си тоже можно обратиться к элементу массива выйдя за пределы массива.
Только это очень сложно будет отловить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:09 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2369
cheblin писал(а):
Цитата:
Ему место заранее зарезервировал и он кучу больше не дергает

reallocation это и есть то самое дерганье кучи.


Я вроде по русски писал - отвел размер с запасом, а при работе с вектором слежу, чтобы его размер не превышал это максимум.
Никакого reallocation нет, проверил в дебаге.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:12 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
я ошибся. прочитал в документации relocate как reallocate. извиняюсь. тут я был не прав.

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:24 
Старожил

Зарегистрирован: 10 фев 2016, 19:55
Сообщения: 298
cheblin писал(а):
в С++ итераторы это банальные указатели, которые после реалокации становятся невалидными

Это не правда. Освежив в памяти инфу, пришёл к выводу, что cheblin скорее прав насчёт итераторов.
cheblin писал(а):
тогда и GC - один из механизмов контроля памяти программистом. ОК

Это, то же не правда.


Последний раз редактировалось Netzschlange 13 сен 2019, 12:11, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 11:42 
Старожил

Зарегистрирован: 10 фев 2016, 19:55
Сообщения: 298
Pingvin, а как Вы исправили ошибку?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 318 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13  След.

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB