AVR на Си++

[mazda]

Кто нибудь не умеет?

[Аlex]

Я не умею.

[mazda]

Есть пара вопросов, по объектам, (не) поможете?

Последний раз редактировалось mazda Чт ноя 09, 2017 10:06:02, всего редактировалось 1 раз.

[Siarzhuk]

mazda писал(а):

по объектам, поможете?

К чёрту условности, джентельмены, спрашивайте всех сразу - Аллах "неумеющих" отсортирует.

[mazda]

что?

[ARV]

куда?

[mazda]

ничего не понимаю

[ARV]

аналогично

[mazda]

есть вопрос по объектам как их вызывать одного типа как бдто бы они в цепочке но что бы не в цепочке тоесть может их стоит как то хитро разместить на памяти в озу но тогда подскажжите пожлйста как это сделать

пс без бквы Y не очень понятно выходит но на клаве она почти не работает так что изеняйте

[ARV]

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

[mazda]

как это не смог, столько лет мог а тит вдрюг не смогю, что то вы не договариваете

[Siarzhuk]

mazda писал(а):

есть вопрос по объектам как их вызывать одного типа как бдто бы они в цепочке но что бы не в цепочке тоесть может их стоит как то хитро разместить на памяти в озу но тогда подскажжите пожлйста как это сделать

Если объекты в течение жизни программы не будут удаляться, создаваться или тусоваться - используем массив. Иначе - используем список. Чтобы уже совсем по С++-ному это std::vector и std::list соответственно - но возвращаясь на эмбедную землю - за простотой этих стандартных контейнеров скрывается неожиданно насыщенное общение с new и malloc , обеспечение комфортной жизни которых в рамках заданной целевой платформы есть отдельная больная тема.

[mazda]

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

[Siarzhuk]

mazda писал(а):

Но пв таком слчае невозможно просто создать класс и его объект в любом месте. Объекты только глобал, классы обёртываются в сложные дефайны.

Т.е. Ключевой вопрос - это унифицированные операции по всем объектам независимо от их [объектов] местоположения? Ну если максимум количества объектов известен - может завести таблицу, хранящую указатели на все живущие сейчас объекты и при необходимости отдать общую команду - проходить по таблице и вызывать соответствуюший метод класса для каждого объекта? Неиспользуемые "слоты" в таблице заполняем NULL-ём. При создании объекта заносим указатель на него в первый NULL-евой слот. При удалении - очищаем его слот в NULL. Таблица может быть приватным статическим методом класса, все операции с ней реализуем в конструкторах/деструкторах и [статических] методах класса. Вроде ничего наружу не должно торчать в этом случае. Ну как, нравится вам такой замысел?

Да, и у каждого свои представления о сложности [дефайнов]. А то меня тут давеча за невинную индексацию делением по модулю анафематствовали ....

PS:

mazda писал(а):

но эти объекты могт быть вложенны дрг в дрга и во что годно ещё.

Хм... посмотрев вооружённым глазом почудился мне тут полиморфизм. Впрочем тоже не проблема - общие методы собираем в кучку, делаем абстрактными, и называем её [эту кучку] заграничным словом interface от которого и наследуем классы объектов.

[mazda]

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

Там не методы общие, но посмотрю как можно прикрутить интерфейсы, правда не увеен что в gcc avr они есть. Там new как такового нет, его нужно реализовывать вручную. Посмотрим.

Но вообще по этой причине и хочу свой парсер си++ с кодогенератором написать, это в теме НАХ КОД описано детальней viewtopic.php?f=57&t=77299

[Siarzhuk]

mazda писал(а):

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

"Общесоюзная" терминология - ключ к пониманию. Что есть "цепочки" в вашем контексте?
И вообще если объекты одинакового размера - организуйте из остатков ram-а пулл и адресная арифметика вам в помощь.

mazda писал(а):

но минус, создать так можно только глобальный объект.

а плюс в том, что из оставшихся возможностей созидания остаются локальные объекты, ведь мы же помним-помним, что использовать кучу вам Папа запретил. А локальные объекты хороши тем, что долго не живут и самоустраняются по мере ухода за горизонт. И на момент применения их количество и положение (вверх по стеку) в общем-то известно. И, да разорвут меня тысяча мышей, если вызов метода класса оператором "точка" или "стрелочка" чем-то отличается для глобальных и локальных объектов - ну кроме особенностей адресации на .data или .stack соответственно.

mazda писал(а):

Там не методы общие, но посмотрю как можно прикрутить интерфейсы, правда не увеен что в gcc avr они есть.

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

[mazda]

если не секрет, сколько лет пишите на плюсах под ВОСЬМИ битные контроллеры с 2-4 килобайтами оперативной памяти, в которой у вас всё, и переменные и стек и куча? На ПК у меня ни разу не срывало стек за последние лет 15, а вот за 4-5 лет работы с авр стек срывало не раз, какая куча, вы что, это очень плохой вариант.

цепочка это я так односвязный список назвал

не очень ясно как объекты "самоустраняются" без операционной системы, ну можно поток с менеджером памяти сделать, но зачем? Лишний раз грузить и без того слабый мк.

[Аlex]

за последние лет 15

А такое ощущение, судя по Вашим вопросам, Вы сели за программирование вчера. Задаёте какие-то школьные вопросы.

не очень ясно как объекты "самоустраняются" без операционной системы

Вы не в курсе, что локальные переменные живут не вечно ? Причём тут ОС ?

за 4-5 лет работы с авр стек срывало не раз, какая куча, вы что, это очень плохой вариант.

Причём тут стек и куча ? Это - две разные вещи, если что. Вы в курсе ?
Стек можно сорвать на раз-два и без всяких сложных манипуляций. И куча для этого вообще не нужна.

Что касается односвязного списка - его можно создать и без дин. выделения памяти. Гуглим, в интернете масса информации по этой теме.

[Siarzhuk]

mazda писал(а):

если не секрет, сколько лет пишите на плюсах под ВОСЬМИ битные контроллеры с 2-4 килобайтами оперативной памяти, в которой у вас всё, и переменные и стек и куча?

Поверьте, "Большой красный флаг" (т.е. AVR в заголовке темы) я сразу заприметил и не упускал из виду ума ни на минуту - чем и заинтересовался как плюсы решат проблему на сиротских ресурсах в столь бюджетной атмосфере. Восьмибитники - мы больше по пичкам хоббиями балуемся - а там плюсов не наблюдается, увы, там фан от забивания ресурсов по максимуму только и остается нам, перфекционанистам. A плюсы, если ембедед - то лет пять тому по работе подписался, потому как "на PC скучно стало". ПАру проектов на LPC 3ххх сначала, сейчас Renesas RX63N основная платформа. Типовое решение как правило с 4 МБайт SDRAM-а - т.е. удовольствие получается ну со-овсем от других решений.

mazda писал(а):

На ПК у меня ни разу не срывало стек за последние лет 15, а вот за 4-5 лет работы с авр стек срывало не раз, какая куча, вы что, это очень плохой вариант.

Кто-же спорит. В Win32 под стек вообще мегабайты дефолтно - там только вечной рекурсией его и можно забороть.

mazda писал(а):

цепочка это я так односвязный список назвал

Так в случае односвязного списка - доп.расход по оперативке тот-же - размер одного указателя, а по глобальной таблице указателей искать вроде как легче - знай инкрементируй указатель да сравнивай? Ну да вам на месте виднее конечно.

mazda писал(а):

не очень ясно как объекты "самоустраняются" без операционной системы, ну можно поток с менеджером памяти сделать, но зачем? Лишний раз грузить и без того слабый мк.

Тут я имел ввиду локальные объекты (т.н. автоматические переменные), что создаются на стеке при входе в функцию (в общем случае) и по выходу из неё прекращающие существование. С++-ные объекты при этом ещё и отрабытывают свои конструкторы/деструкторы. Ну т.е. компилятор вставляет неявные их вызовы. А мусоросборщик городить - на самом деле, зачем....

[mazda]

Аlex писал(а):

за последние лет 15

Что касается односвязного списка - его можно создать и без дин. выделения памяти. Гуглим, в интернете масса информации по этой теме.

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

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

Добавлено after 6 minutes 37 seconds:

Siarzhuk писал(а):

Тут я имел ввиду локальные объекты (т.н. автоматические переменные), что создаются на стеке при входе в функцию (в общем случае) и по выходу из неё прекращающие существование. С++-ные объекты при этом ещё и отрабытывают свои конструкторы/деструкторы. Ну т.е. компилятор вставляет неявные их вызовы. А мусоросборщик городить - на самом деле, зачем....

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

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