ООП. Классы и динамические объекты, Подробности управления «кучей» Опции

[Serhiy_UA]

Динамические объекты создаются и уничтожаются в памяти «кучи» (heap) с помощью доступных программисту операторов new/delete. В порядке самообразования по С++ хотел бы уточнить следующие скрытые от нас подробности:
1. Действия по динамическому размещению полей данных объекта в куче выполняет прикладная программа или операционная система?
2. Если за размещение в куче ответственна ОС, то все ли из ОС поддерживают динамические объекты (и в частности для встраиваемых систем)? И как в таком случае обслуживается одновременная работа нескольких активных на данный момент программ с общей кучей, или у каждой программы своя куча?
3. Если полей данных у конкретного объекта много, то его данные размещаются в памяти непрерывно или с разрывами (перескоками), в зависимости от текущего состояния кучи ?
4. Что можно почитать на эту тему по-подробней?

[sigmaN]

А дальше можно изучить мысли товарища Александреску по этому поводу
https://erdani.com/publications/cuj-2005-12.pdf
И более свежий, интересный видос
https://youtu.be/LIb3L4vKZ7U

[Serhiy_UA]

Спасибо за разъяснения.
Пока еще не все понятно, но мнение мое по этому вопросу складывается такое.
Память под «кучу» упорядочивается и представляется, как бы в виде большой кассеты с группами коробочек разных величин. При создании объекта, ему выделяется нужная по размеру коробочка, а если они закончились, то большая из ближайшей группы. Если коробочек уже не хватает, то на основе статистики о требуемых размерах памяти создают следующую кассету. Для кассеты ведется текущий реестр учета свободных и занятых коробок, по которому и выделяется указатель на свободную память. То есть, кучи, и тем более «мало-кучи» в нашем понимании, как токовой нет, а все как бы строго упорядочено и физическая память под один динамический объект все же непрерывна, а не размазана с разрывами по её разным областям.
Поправьте, если понял не так…

[Сергей Борщ]

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

Это всего лишь одна из очень многих стратегий. На начальном этапе вы можете об этом не задумываться. Вы просто можете пока считать, что есть некая "куча" из которой вам выделят непрерывный кусок запрошенного вами размера. Или не выделят, если непрерывного куска запрошенного размера в данный момент в куче нет.

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

Это вам сказали в самом первом ответе. Как же может быть иначе? Система же не знает, что вы там хотите разместить. Но вы можете некоторые данные своего объекта хранить отдельно, в дополнительно запрашиваемой памяти. Запрашивать ее можно в конструкторе, а освобождать - в деструкторе.

[jcxz]

Это вам сказали в самом первом ответе. Как же может быть иначе? Система же не знает, что вы там хотите разместить. Но вы можете некоторые данные своего объекта хранить отдельно, в дополнительно запрашиваемой памяти. Запрашивать ее можно в конструкторе, а освобождать - в деструкторе.

В общем случае - это не так.
Никто не мешает системе, в распоряжении которой есть MMU, сделать маппирование одного сплошного диапазона логических адресов (блока памяти выделяемого пользовательскому ПО) на несколько несмежных диапазонов физических адресов.
А вот делает-ли такое какая-то конкретная ОС или нет - не знаю.

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

Вменяемый может даже несмежные физические блоки объединить. Воспользовавшись услугами MMU.

[AlexandrY]

Вменяемый может даже несмежные физические блоки объединить. Воспользовавшись услугами MMU.

Да, но на каком уровне это MMU задействуется?
Думаю что штатные менеджеры, скажем на PC, не привлекают MMU. Это слишком затратно по времени.
MMU могут привлечь для всего блока памяти кучи, но не для выделения и объединения фрагментов.

[jcxz]

Думаю что штатные менеджеры, скажем на PC, не привлекают MMU. Это слишком затратно по времени.

Ну - не очень затратно. Например: можно реализовать это в обработчике void * недостаточно_памяти(ulong требуемый_размер)
Такой обработчик может собрать имеющиеся разрозненные свободные блоки и в специально выделенном диапазоне лог. адресов построить карту перемаппирования, сохранить себе полученный лог.адрес и вернуть его. В delete надо будет конечно сделать проверку на предмет освобождения такого блока.
В некоторых случаях думаю важнее всё-таки получить память, пусть и чуть медленнее. Но медленее будет идти работа только с этими блоками, с обычными блоками - примерно так же.
Не говорю что это где-то так реализовано. Просто это возможно.