Динамически выделенная область памяти привязана к указателю на объект. Методы лежат во флеше, и вызываются через указатель. Данные лежат в оперативке. Тут нет никаких загадок - переменные в оперативке, действия на флешке.

ARV, при всём уважении, но вы написали дикую сушённую херь.

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

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

И при чём тут виртуальная таблица? Ну не создавайте вы виртуальные методы и её не будет, и да она всегда в оперативке на авр, а адреса объектов никогда не могут быть константами и параметрами шаблонов, по крайней мере до с++11, дальше не пробовал.

Не понимаю ваше удивления о том что оказывается объекты распологаются в озу? А где же ещё? Допускаю что вы путаете сами методы и поля данных, это так?


Если что, поправляйте, я сам не мастер по плюсам, и не программист.



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

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

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

так что фрагментация кучи - не первая в списке проблема.

P.S. я в курсе, что случаи бывают разные.

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

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

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

посмотрите выше, я там расписал конкретный пример где это допустимо. Никто и не применяет подходы с ПК к МК, тем более к авр8, иначе этой темы не было бы, потому что vector или list или любой подходящий контейнер объектов подошёл бы.

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

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

Подробнее>>

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

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

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

Подробнее>>

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

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

я вас научу работать

..., вы все у меня умоотводы напялите !
viewtopic.php?f=57&t=149935
Похоже, форуму срочно требуется админ с дипломом психиатра.
ARV, у Вас же такового нет? "Не навреди!" - любил говаривать старик Гиппократ.

это регулярно звучащая фраза нашего директора

Дело в том, что "другие" находятся в порочном плену у типовых паттернов, и уже смирились с тем, что для организации простейшего списка придётся расплачиваться оперативкой в количестве sizeof(T*) на экземпляр объекта. А для разнородных объектов ещё и +sizeof(VMT*) в лучшем случае. И весь комфорт с new по умолчанию полагается на динамическую память [если никто не рассказал про placement new]. Поэтому ваше утверждение что удалось обойтись без первого, второго и третьего и вызвало фуррор в определённых кругах и ожидание [несбывшегося впрочем] раскрытия деталей такой реализации. В общем случае 1) информация об объекте должна где-то храниться; 2) информация о следующем объекте в списке должна иметься в наличии - либо явно [в указателе], либо косвенно [размер данного объекта в пуле]. Как только сумма затрат на это сравнивается с sizeof(T*) [+sizeof(VMT*)] время потраченное на доморощенную упаковку можно считать потраченным впустую.

Вопрос не о количестве свойств объекта, вопрос о количестве параметров шаблона по которому строится объект. Свойства инициализируются при конструировании и модифицируются методами во время исполнения. Параметры шаблона определяют объект во время компиляции. И если от 70 параметров шаблона типа int& ни структура данных объекта, ни методы с ней работающие не меняются - с таким-же успехом эти ссылки могли отправиться в список параметров функции-конструктора. Если-же это попытка избежать затрат на разыменование this и затрат на передачу параметров в функции прямым обращением к глобальным данным - почему-бы и нет? Правда одна из основных черепах на которых стоит слон ООП - инкапсуляция, в этом случае будет смертельно обижена на такое ваше "Си с темплейтами".

Добавлено after 1 minute 6 seconds:

А вторая по популярности фраза часом не "А зачем вам столько денег?"

лень подробно расписывать все ответы на выши вопросы, они есть в моих комментариях выше, и про new и шаблоны и тд

со спискос вы ошиблись, на создание односвязного списка уйдёт память на объекты и на адреса, а при односвязных списках разных классов - размер объекта + размер адреса ( 2 байта) + размер адреса функции позволяющей обратиться правильным образом к объекту класса для которой эта функция предназначена( 2 байта озу и чуток флэш), она же статический метод класса, принимает int16 и представляя его как указатель на объект своего класса вызывает интрфейсный метод, если нужно то с параметрами, например с номером обращения

new - у меня компилятор не знает что это, он знает это ключевое слово, но его ОБЯЗАТЕЛЬНО НУЖНО ПИСАТЬ САМОМУ, компилятор GCC4... для АВР new не знает, как и placement new

следующая фраза "ну как так то"