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

Я не умею.

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

что?

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

куда?

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

аналогично

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

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

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

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

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

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

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

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

PS:


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

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

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

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

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


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


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

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

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

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

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

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

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

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


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


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


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

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

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

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


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

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