Реальная затрачиваемая память в динамике

@Izual · Регистрация: 13.11.2012

Студворк — интернет-сервис помощи студентам

Динамическое выделение памяти.. допустим есть:

C++
1
int *ivar=new int[255] ;

Поидее при выделении должно выделиться 255*4 байт памяти, однако при использовании delete программа заведомо знает данный размер (255*4), а значит этот размер где то хранится. Так вот, для хранения размера чисто логически - значит положена ещё одна переменная. (при этом подозреваю, что при 32б архитектуре эта переменная будет 4 байтной, т.к. в 4 байта влазиет адрес максимума 4ГБ, соответственно в 64б арх. - переменная будет 8 байтной).
Ну и получается, что по крайней мере помимо 255*4 байт, выделяется ещё 4 байта, которые будут хранить размер. Но ведь и это по сути может быть не предел, может там есть ещё какие то необходимые поля.
Может кто знает, или где почитать? (т.к. ссылки на другие сайты запрещены, можете выложить ключевую фразу для гугла или яндекса, чтоб сразу найти)

Почему собственно данный вопрос возник.. Сижу разбираю статью о кастомных аллокаторах ("Альтернативные аллокаторы памяти" на хабре), где достаточно интересно представленны манипуляции с выделением памяти.. при использовании обычных аллокаторов new и calloc никогда и не задумываешся о том, что же на самом деле происходит "внутри", а ведь это достаточно интересно).

Так вот, и подумалось.. а зачем собственно нам нужны все эти union'ы и варианты, где вечно встаёт вопрос о "неиспользуемой памяти" при выделении памяти для POD типов меньших размеров чем сами структуры. Не проще ли было бы использовать указатель смещения, в место того, чтоб полагаться на устройство ОС в отношении выделяемых объектов.
Имею ввиду что то типа переменной uint8_t *mem в примере из статьи:

C++
1
2
3
4
5
typedef struct _LinearBuffer {
uint8_t *mem;       /*!< Pointer to buffer memory. */
uint32_t totalSize; /*!< Total size in bytes. */
uint32_t offset;    /*!< Offset. */
} LinearBuffer;

А если мы можем сами контролировать реальные размер памяти, то и меньше проблем было бы с размером и фрагментацией.

@gng · 18.09.2016, 22:48

Сообщение от Izual

Поидее при выделении должно выделиться 255*4 байт памяти, однако при использовании delete программа заведомо знает данный размер (255*4), а значит этот размер где то хранится.

Какой вы сообразительный!
Во многих реализациях new и delete вызывают malloc и free из libc. А libc действительно, хранит размеры всех выделяемых блоков и при необходимости запрашивает память у ядра ОС.
Но теоретически возможна реализация new и delete, когда компилятор зарание берет у системы блок памяти определенного размера, и тогда известные на стадии компиляции размеры блоков можно и не хранить. Это, насколько я понимаю, вам и пытались втолковать.

Сообщение от Izual

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

Да, ваша интуиция впечатляет. Дествительно, многие реализации libc в конце выделенного блока добавляют информацию для контроля переполнения. Впрочем, вам об этом уже тоже сказали.

Сообщение от Izual

Может кто знает, или где почитать?

Читать лучше оригиналы. В данном случае это исходники malloc и free из libc. Многие из них (напр. glibc) открыты. Читайте и просвещайтесь.

Сообщение от Izual

А если мы можем сами контролировать реальные размер памяти, то и меньше проблем было бы с размером и фрагментацией.

Если словом "мы" вы обозначаете себя, то, думаю, проблем будет больше.

@Izual · 18.09.2016, 22:53 **[ТС]**

Сообщение от gng

Но теоретически возможна реализация new и delete, когда компилятор зарание берет у системы блок памяти определенного размера, и тогда известные на стадии компиляции размеры блоков можно и не хранить. Это, насколько я понимаю, вам и пытались втолковать.

Хмм.. тема была о другом и обсуждалось другое.. ну да ладно

Сообщение от gng

Если словом "мы" вы обозначаете себя, то, думаю, проблем будет больше.

не ссуть.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 15 неявная схема anaschu 29.06.2026 Алиса Калибровка параметров симбиотической модели: технический обзор Содержание: Введение Постановка проблемы Технические аспекты реализации Процесс внедрения изменений	сукцессия 14. Обновленная схема модели anaschu 28.06.2026 ГЛОБАЛЬНАЯ ОПИСАТЕЛЬНАЯ СПЕЦИФИКАЦИЯ ЭКОСИСТЕМНОЙ МОДЕЛИ «SOIL CHEMISTRY & MYCORRHIZA 2. 0» https:/ / ibb. co/ NnkGpfMd Представленная интегрированная схема описывает непрерывную нелинейную. . .	сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .
Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .	10 сукцессия. Питон код войны грибов и растений anaschu 27.06.2026 import numpy as np class PlantAgent: def __init__(self, name, strategy, initial_biomass): self. name = name self. strategy = strategy # "greedy" (широколиственные) или. . .	сукцессия 9. Математика подлости: как растения предали грибных друзей anaschu 27.06.2026 Статья 2. Глобальная фосфорная война: эволюционно-экономические механизмы распределения биомов Земли Введение: Экологический рынок как игра с нулевой суммой Традиционная экология долгое время. . .	сукцессия 8. Как я спорил с ИИ, которые - агенты растений и ненавистники грибов! anaschu 27.06.2026 Статья 1. Хроники грибного восстания: как Сократов диалог разрушил академические догмы ИИ Введение: Синдром «цифрового учебника» Современные большие языковые модели (LLM) обладают колоссальным. . .