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

Мы открыли для себя возможности динамического выделения памяти. Что это значит? Это значит то, что при динамическом выделении памяти, память резервируется не на этапе компиляции а на этапе выполнения программы. И это дает нам возможность выделять память более эффективно, в основном это касается массивов. С динамическим выделением память, нам нет необходимости заранее задавать размер массива, тем более, что не всегда известно, какой размер должен быть у массива. Далее рассмотрим каким же образом можно выделять память.

Выделение памяти в Си (функция malloc)

Функция malloc() определена в заголовочном файле stdlib.h , она используется для инициализации указателей необходимым объемом памяти. Память выделяется из сектора оперативной памяти доступного для любых программ, выполняемых на данной машине. Аргументом является количество байт памяти, которую необходимо выделить, возвращает функция — указатель на выделенный блок в памяти. Функция malloc() работает также как и любая другая функция, ничего нового.

Так как различные типы данных имеют разные требования к памяти, мы как-то должны научиться получить размер в байтах для данных разного типа. Например, нам нужен участок памяти под массив значений типа int — это один размер памяти, а если нам нужно выделить память под массив того же размера, но уже типа char — это другой размер. Поэтому нужно как-то вычислять размер памяти. Это может быть сделано с помощью операции sizeof() , которая принимает выражение и возвращает его размер. Например, sizeof(int) вернет количество байтов, необходимых для хранения значения типа int . Рассмотрим пример:

#include int *ptrVar = malloc(sizeof(int));

В этом примере, в строке 3 указателю ptrVar присваивается адрес на участок памяти, размер которого соответствует типу данных int . Автоматически, этот участок памяти становится недоступным для других программ. А это значит, что после того, как выделенная память станет ненужной, её нужно явно высвободить. Если же память не будет явно высвобождена, то по завершению работы программы, память так и не освободится для операционной системы, это называется утечкой памяти. Также можно определять размер выделяемой памяти, которую нужно выделить передавая пустой указатель, вот пример:

Int *ptrVar = malloc(sizeof(*ptrVar));

Что здесь происходит? Операция sizeof(*ptrVar) оценит размер участка памяти, на который ссылается указатель. Так как ptrVar является указателем на участок памяти типа int , то sizeof() вернет размер целого числа. То есть, по сути, по первой части определения указателя, вычисляется размер для второй части. Так зачем же это нам надо? Это может понадобиться, если вдруг необходимо поменять определение указателя, int , например, на float и тогда, нам не нужно менять тип данных в двух частях определения указателя. Достаточно будет того, что мы поменяем первую часть:

Float *ptrVar = malloc(sizeof(*ptrVar));

Как видите, в такой записи есть одна очень сильная сторона, мы не должны вызывать функцию malloc() с использованием sizeof(float) . Вместо этого мы передали в malloc() указатель на тип float , в таком случае, размер выделяемой памяти автоматически определится сам!

Особенно это пригодится, если выделять память потребуется далеко от определения указателя:

Float *ptrVar; /* . . . сто строк кода */ . . . ptrVar = malloc(sizeof(*ptrVar));

Если бы вы использовали конструкцию выделения памяти с операцией sizeof() , то вам бы пришлось находить в коде определение указателя, смотреть его тип данных и уже потом вы бы смогли правильно выделить память.

Высвобождение выделенной памяти

Высвобождение памяти выполняется с помощью функции free() . Вот пример:

Free(ptrVar);

После освобождения памяти, хорошей практикой является сброс указателя в нуль, то есть присвоить *ptrVar = 0 . Если указателю присвоить 0, указатель становится нулевым, другими словами, он уже никуда не указывает. Всегда после высвобождения памяти, присваивайте указателю 0, в противном случае, даже после высвобождения памяти, указатель все равно на неё указывает, а значит вы случайно можете нанести вред другим программам, которые, возможно будут использовать эту память, но вы даже ничего об этом не узнаете и будете думать, что программа работает корректно.

P.S.: Всем, кто увлекается видеомонтажом может быть интересен этот редактор видео Windows 7 . Видеоредактор называется Movavi, может кто-то уже с ним знаком или даже работал с ним. С помощью этой программы на русском языке, вы легко можете добавить видео с камеры, улучшить качество и наложить красивые видео эффекты.

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

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

0. А нужна ли нам ручная работа с памятью?

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

Напишем простые тесты для C++ и C# (C# известен прекрасным менеджером памяти, который делит объекты по поколениям, использует разные пулы для объектов разных размеров и т.п.).

Class Node { public: Node* next; }; // ... for (int i = 0; i < 10000000; i++) { Node* v = new Node(); }

Class Node { public Node next; } // ... for (int l = 0; l < 10000000; l++) { var v = new Node(); }

Несмотря на всю «сферично-вакуумность» примера, разница по времени получилась в 10 раз (62 ms против 650 ms). Кроме того, c#-пример закончен, а по правилам хорошего тона в c++ выделенные объекты надо удалить, что ещё больше увеличит отрыв (до 2580 ms).

1. Пул объектов

Очевидное решение - забрать у ОС большой блок памяти и разбить его на равные блоки размера sizeof(Node), при выделении памяти брать блок из пула, при освобождении - возвращать в пул. Пул проще всего организовать с помощью односвязного списка (стека).

Поскольку стоит задача минимального вмешательства в программу, всё что можно будет сделать, это добавить примесь BlockAlloc к классу Node:
class Node: public BlockAlloc

Прежде всего нам понадобится пул больших блоков (страниц), которые забираем у ОС или C-runtime. Его можно организовать поверх функций malloc и free, но для большей эффективности (чтобы пропустить лишний уровень абстракции), используем VirtualAlloc/VirtualFree. Эти функции выделяют память блоками, кратными 4K, а также резервируют адресное пространство процесса блоками, кратными 64K. Одновременно указывая опции commit и reserve, мы перескакиваем ещё один уровень абстракции, резервируя адресное пространство и выделяя страницы памяти одним вызовом.

Класс PagePool

inline size_t align(size_t x, size_t a) { return ((x-1) | (a-1)) + 1; } //#define align(x, a) ((((x)-1) | ((a)-1)) + 1) template class PagePool { public: void* GetPage() { void* page = VirtualAlloc(NULL, PageSize, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); pages.push_back(page); return page; } ~PagePool() { for (vector::iterator i = pages.begin(); i != pages.end(); ++i) { VirtualFree(*i, 0, MEM_RELEASE); } } private: vector pages; };

Затем организуем пул блоков заданного размера

Класс BlockPool

template class BlockPool: PagePool { public: BlockPool() : head(NULL) { BlockSize = align(sizeof(T), Alignment); count = PageSize / BlockSize; } void* AllocBlock() { // todo: lock(this) if (!head) FormatNewPage(); void* tmp = head; head = *(void**)head; return tmp; } void FreeBlock(void* tmp) { // todo: lock(this) *(void**)tmp = head; head = tmp; } private: void* head; size_t BlockSize; size_t count; void FormatNewPage() { void* tmp = GetPage(); head = tmp; for(size_t i = 0; i < count-1; i++) { void* next = (char*)tmp + BlockSize; *(void**)tmp = next; tmp = next; } *(void**)tmp = NULL; } };

Комментарием // todo: lock(this) помечены места, которые требуют межпоточной синхронизации (например, используйте EnterCriticalSection или boost::mutex).

Объясню, почему при «форматировании» страницы не ипользуется абстракция FreeBlock для добавления блока в пул. Если бы было написано что-то вроде

For (size_t i = 0; i < PageSize; i += BlockSize) FreeBlock((char*)tmp+i);

То страница по принципу FIFO оказалась бы размеченной «наоборот»:

Несколько блоков, затребованных из пула подряд, имели бы убывающие адреса. А процессор не любит ходить назад, от этого у него ломается Prefetch (UPD : Не актуально для современных процессоров). Если же делать разметку в цикле
for (size_t i = PageSize-(BlockSize-(PageSize%BlockSize)); i != 0; i -= BlockSize) FreeBlock...
то цикл разметки ходил бы по адресам назад.

Теперь, когда приготовления сделаны, можно описать класс-примесь.
template class BlockAlloc { public: static void* operator new(size_t s) { if (s != sizeof(T)) { return::operator new(s); } return pool.AllocBlock(); } static void operator delete(void* m, size_t s) { if (s != sizeof(T)) { ::operator delete(m); } else if (m != NULL) { pool.... static void* operator new(size_t, void* m) { return m; } // ...and the warning about missing placement delete... static void operator delete(void*, void*) { } private: static BlockPool pool; }; template BlockPool BlockAlloc::pool;

Объясню, зачем нужны проверки if (s != sizeof(T))
Когда они срабатывают? Тогда, когда создаётся/удаляется класс, отнаследованный от базового T.
Наследники будут пользоваться обычными new/delete, но к ним также можно примешать BlockAlloc. Таким образом, мы легко и безопасно определяем, какие классы должны пользоваться пулами, не боясь сломать что-то в программе. Множественное наследование также прекрасно работает с этой примесью.

Готово. Наследуем Node от BlockAlloc и заново проводим тест.
Время теста теперь - 120 ms. В 5 раз быстрее. Но в c# аллокатор всё же лучше. Наверное, там не просто связный список. (Если же сразу после new сразу вызывать delete, и тем самым не тратить много памяти, умещая данные в кеш, получим 62 ms. Странно. В точности, как у.NET CLR, как будто он возвращает освободившиеся локальные переменные сразу в соответствующий пул, не дожидаясь GC)

2. Контейнер и его пёстрое содержимое

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

Например, это может быть класс XmlDocument, наполненный классами Node и Attribute, а также c-строками (char*), взятыми из текста внутри нод. Или список файлов и каталогов в файловом менеджере, загружаемых один раз при перечитывании каталога и больше не меняющихся.

Как было показано во введении, delete обходится дороже, чем new. Идея второй части статьи в том, чтобы память под дочерние объекты выделять в большом блоке, связанном с Parent-объектом. При удалении parent-объекта у дочерних будут, как обычно, вызваны деструкторы, но память возвращать не потребуется - она освободиться одним большим блоком.

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

Класс PointerBumpAllocator

template class PointerBumpAllocator { public: PointerBumpAllocator() : free(0) { } void* AllocBlock(size_t block) { // todo: lock(this) block = align(block, Alignment); if (block > free) { free = align(block, PageSize); head = GetPage(free); } void* tmp = head; head = (char*)head + block; free -= block; return tmp; } ~PointerBumpAllocator() { for (vector::iterator i = pages.begin(); i != pages.end(); ++i) { VirtualFree(*i, 0, MEM_RELEASE); } } private: void* GetPage(size_t size) { void* page = VirtualAlloc(NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); pages.push_back(page); return page; } vector pages; void* head; size_t free; }; typedef PointerBumpAllocator<> DefaultAllocator;

Наконец, опишем примесь ChildObject с перегруженными new и delete, обращающимися к заданному аллокатору:

Template struct ChildObject { static void* operator new(size_t s, A& allocator) { return allocator.AllocBlock(s); } static void* operator new(size_t s, A* allocator) { return allocator->AllocBlock(s); } static void operator delete(void*, size_t) { } // *1 static void operator delete(void*, A*) { } static void operator delete(void*, A&) { } private: static void* operator new(size_t s); };

В этом случае кроме добавления примеси в child-класс необходимо будет также исправить все вызовы new (или воспользоваться паттерном «фабрика»). Синтаксис оператора new будет следующим:

New (… параметры для оператора…) ChildObject (… параметры конструктора…)

Для удобства я задал два оператора new, принимающих A& или A*.
Если аллокатор добавлен в parent-класс как член, удобнее первый вариант:
node = new(allocator) XmlNode(nodename);
Если аллокатор добавлен как предок (примесь), удобнее второй:
node = new(this) XmlNode(nodename);

Для вызова delete не предусмотрен специальный синтаксис, компилятор вызовет стандартный delete (отмеченный *1), независимо от того, какой из операторов new был использован для создания объекта. То есть, синтаксис delete обычный:
delete node;

Если же в конструкторе ChildObject (или его наследника) происходит исключение, вызывается delete с сигнатурой, соответствующей сигнатуре оператора new, использованном при создании этого объекта (первый параметр size_t будет заменён на void*).

Размешение оператора new в секции private защищает от вызова new без указания аллокатора.

Приведу законченный пример использования пары Allocator-ChildObject:

Пример

class XmlDocument: public DefaultAllocator { public: ~XmlDocument() { for (vector::iterator i = nodes.begin(); i != nodes.end(); ++i) { delete (*i); } } void AddNode(char* content, char* name) { char* c = (char*)AllocBlock(strlen(content)+1); strcpy(c, content); char* n = (char*)AllocBlock(strlen(name)+1); strcpy(n, content); nodes.push_back(new(this) XmlNode(c, n)); } class XmlNode: public ChildObject { public: XmlNode(char* _content, char* _name) : content(_content), name(_name) { } private: char* content; char* name; }; private: vector nodes; };

Заключение. Статья была написана 1.5 года назад для песочницы, но увы, не понравилась модератору.

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

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

0. А нужна ли нам ручная работа с памятью?

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

Напишем простые тесты для C++ и C# (C# известен прекрасным менеджером памяти, который делит объекты по поколениям, использует разные пулы для объектов разных размеров и т.п.).

Class Node { public: Node* next; }; // ... for (int i = 0; i < 10000000; i++) { Node* v = new Node(); }

Class Node { public Node next; } // ... for (int l = 0; l < 10000000; l++) { var v = new Node(); }

Несмотря на всю «сферично-вакуумность» примера, разница по времени получилась в 10 раз (62 ms против 650 ms). Кроме того, c#-пример закончен, а по правилам хорошего тона в c++ выделенные объекты надо удалить, что ещё больше увеличит отрыв (до 2580 ms).

1. Пул объектов

Очевидное решение - забрать у ОС большой блок памяти и разбить его на равные блоки размера sizeof(Node), при выделении памяти брать блок из пула, при освобождении - возвращать в пул. Пул проще всего организовать с помощью односвязного списка (стека).

Поскольку стоит задача минимального вмешательства в программу, всё что можно будет сделать, это добавить примесь BlockAlloc к классу Node:
class Node: public BlockAlloc

Прежде всего нам понадобится пул больших блоков (страниц), которые забираем у ОС или C-runtime. Его можно организовать поверх функций malloc и free, но для большей эффективности (чтобы пропустить лишний уровень абстракции), используем VirtualAlloc/VirtualFree. Эти функции выделяют память блоками, кратными 4K, а также резервируют адресное пространство процесса блоками, кратными 64K. Одновременно указывая опции commit и reserve, мы перескакиваем ещё один уровень абстракции, резервируя адресное пространство и выделяя страницы памяти одним вызовом.

Класс PagePool

inline size_t align(size_t x, size_t a) { return ((x-1) | (a-1)) + 1; } //#define align(x, a) ((((x)-1) | ((a)-1)) + 1) template class PagePool { public: void* GetPage() { void* page = VirtualAlloc(NULL, PageSize, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); pages.push_back(page); return page; } ~PagePool() { for (vector::iterator i = pages.begin(); i != pages.end(); ++i) { VirtualFree(*i, 0, MEM_RELEASE); } } private: vector pages; };

Затем организуем пул блоков заданного размера

Класс BlockPool

template class BlockPool: PagePool { public: BlockPool() : head(NULL) { BlockSize = align(sizeof(T), Alignment); count = PageSize / BlockSize; } void* AllocBlock() { // todo: lock(this) if (!head) FormatNewPage(); void* tmp = head; head = *(void**)head; return tmp; } void FreeBlock(void* tmp) { // todo: lock(this) *(void**)tmp = head; head = tmp; } private: void* head; size_t BlockSize; size_t count; void FormatNewPage() { void* tmp = GetPage(); head = tmp; for(size_t i = 0; i < count-1; i++) { void* next = (char*)tmp + BlockSize; *(void**)tmp = next; tmp = next; } *(void**)tmp = NULL; } };

Комментарием // todo: lock(this) помечены места, которые требуют межпоточной синхронизации (например, используйте EnterCriticalSection или boost::mutex).

Объясню, почему при «форматировании» страницы не ипользуется абстракция FreeBlock для добавления блока в пул. Если бы было написано что-то вроде

For (size_t i = 0; i < PageSize; i += BlockSize) FreeBlock((char*)tmp+i);

То страница по принципу FIFO оказалась бы размеченной «наоборот»:

Несколько блоков, затребованных из пула подряд, имели бы убывающие адреса. А процессор не любит ходить назад, от этого у него ломается Prefetch (UPD : Не актуально для современных процессоров). Если же делать разметку в цикле
for (size_t i = PageSize-(BlockSize-(PageSize%BlockSize)); i != 0; i -= BlockSize) FreeBlock...
то цикл разметки ходил бы по адресам назад.

Теперь, когда приготовления сделаны, можно описать класс-примесь.
template class BlockAlloc { public: static void* operator new(size_t s) { if (s != sizeof(T)) { return::operator new(s); } return pool.AllocBlock(); } static void operator delete(void* m, size_t s) { if (s != sizeof(T)) { ::operator delete(m); } else if (m != NULL) { pool.FreeBlock(m); } } // todo: implement nothrow_t overloads, according to borisko" comment // http://habrahabr.ru/post/148657/#comment_5020297 // Avoid hiding placement new that"s needed by the stl containers... static void* operator new(size_t, void* m) { return m; } // ...and the warning about missing placement delete... static void operator delete(void*, void*) { } private: static BlockPool pool; }; template BlockPool BlockAlloc::pool;

Объясню, зачем нужны проверки if (s != sizeof(T))
Когда они срабатывают? Тогда, когда создаётся/удаляется класс, отнаследованный от базового T.
Наследники будут пользоваться обычными new/delete, но к ним также можно примешать BlockAlloc. Таким образом, мы легко и безопасно определяем, какие классы должны пользоваться пулами, не боясь сломать что-то в программе. Множественное наследование также прекрасно работает с этой примесью.

Готово. Наследуем Node от BlockAlloc и заново проводим тест.
Время теста теперь - 120 ms. В 5 раз быстрее. Но в c# аллокатор всё же лучше. Наверное, там не просто связный список. (Если же сразу после new сразу вызывать delete, и тем самым не тратить много памяти, умещая данные в кеш, получим 62 ms. Странно. В точности, как у.NET CLR, как будто он возвращает освободившиеся локальные переменные сразу в соответствующий пул, не дожидаясь GC)

2. Контейнер и его пёстрое содержимое

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

Например, это может быть класс XmlDocument, наполненный классами Node и Attribute, а также c-строками (char*), взятыми из текста внутри нод. Или список файлов и каталогов в файловом менеджере, загружаемых один раз при перечитывании каталога и больше не меняющихся.

Как было показано во введении, delete обходится дороже, чем new. Идея второй части статьи в том, чтобы память под дочерние объекты выделять в большом блоке, связанном с Parent-объектом. При удалении parent-объекта у дочерних будут, как обычно, вызваны деструкторы, но память возвращать не потребуется - она освободиться одним большим блоком.

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

Класс PointerBumpAllocator

template class PointerBumpAllocator { public: PointerBumpAllocator() : free(0) { } void* AllocBlock(size_t block) { // todo: lock(this) block = align(block, Alignment); if (block > free) { free = align(block, PageSize); head = GetPage(free); } void* tmp = head; head = (char*)head + block; free -= block; return tmp; } ~PointerBumpAllocator() { for (vector::iterator i = pages.begin(); i != pages.end(); ++i) { VirtualFree(*i, 0, MEM_RELEASE); } } private: void* GetPage(size_t size) { void* page = VirtualAlloc(NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); pages.push_back(page); return page; } vector pages; void* head; size_t free; }; typedef PointerBumpAllocator<> DefaultAllocator;

Наконец, опишем примесь ChildObject с перегруженными new и delete, обращающимися к заданному аллокатору:

Template struct ChildObject { static void* operator new(size_t s, A& allocator) { return allocator.AllocBlock(s); } static void* operator new(size_t s, A* allocator) { return allocator->AllocBlock(s); } static void operator delete(void*, size_t) { } // *1 static void operator delete(void*, A*) { } static void operator delete(void*, A&) { } private: static void* operator new(size_t s); };

В этом случае кроме добавления примеси в child-класс необходимо будет также исправить все вызовы new (или воспользоваться паттерном «фабрика»). Синтаксис оператора new будет следующим:

New (… параметры для оператора…) ChildObject (… параметры конструктора…)

Для удобства я задал два оператора new, принимающих A& или A*.
Если аллокатор добавлен в parent-класс как член, удобнее первый вариант:
node = new(allocator) XmlNode(nodename);
Если аллокатор добавлен как предок (примесь), удобнее второй:
node = new(this) XmlNode(nodename);

Для вызова delete не предусмотрен специальный синтаксис, компилятор вызовет стандартный delete (отмеченный *1), независимо от того, какой из операторов new был использован для создания объекта. То есть, синтаксис delete обычный:
delete node;

Если же в конструкторе ChildObject (или его наследника) происходит исключение, вызывается delete с сигнатурой, соответствующей сигнатуре оператора new, использованном при создании этого объекта (первый параметр size_t будет заменён на void*).

Размешение оператора new в секции private защищает от вызова new без указания аллокатора.

Приведу законченный пример использования пары Allocator-ChildObject:

Пример

class XmlDocument: public DefaultAllocator { public: ~XmlDocument() { for (vector::iterator i = nodes.begin(); i != nodes.end(); ++i) { delete (*i); } } void AddNode(char* content, char* name) { char* c = (char*)AllocBlock(strlen(content)+1); strcpy(c, content); char* n = (char*)AllocBlock(strlen(name)+1); strcpy(n, content); nodes.push_back(new(this) XmlNode(c, n)); } class XmlNode: public ChildObject { public: XmlNode(char* _content, char* _name) : content(_content), name(_name) { } private: char* content; char* name; }; private: vector nodes; };

Заключение. Статья была написана 1.5 года назад для песочницы, но увы, не понравилась модератору.

Итак. третий тип, самый интересный в этой теме для нас – динамический тип памяти.

Как мы работали с массивами раньше? int a Как мы работаем сейчас? Выделяем столько, сколько нужно:

#include < stdio.h> #include < stdlib.h> int main () { size_t size; // Создаём указатель на int // – по сути, пустой массив. int *list; scanf (" %lu " , &size); // Выделяем память для size элементов размером int // и наш "пустой массив" теперь ссылается на эту память. list = (int *)malloc (size * sizeof (int )); for (int i = 0 ; i < size; ++i) { scanf (" %d " < size; ++i) { printf (" %d " , *(list + i)); } // Не забываем за собой прибраться! free (list); } // *

Void * malloc(size_t size);

Но в общем и целом это функция, выделяет size байт неинициализированной памяти (не нули, а мусор).

Если выделение прошло успешно, то возвращается указатель на самый первый байт выделенной памяти.

Если неуспешно – NULL. Также errno будет равен ENOMEM (эту замечательную переменную мы рассмотрим позднее). То есть правильнее было написать:

#include < stdio.h> #include < stdlib.h> int main () { size_t size; int *list; scanf (" %lu " , &size); list = (int *)malloc (size * sizeof (int )); if (list == NULL ) { goto error; } for (int i = 0 ; i < size; ++i) { scanf (" %d " , list + i); } for (int i = 0 ; i < size; ++i) { printf (" %d " , *(list + i)); } free (list); return 0 ; error: return 1 ; } // *

Очищать NULL указатель не нужно

#include < stdlib.h> int main () { free (NULL ); }

– в том же clang всё пройдёт нормально (сделает ничто), но в более экзотических случаях вполне может крэшнуть программу.

Рядом с malloc и free в мане можно увидеть ещё:

void * calloc (size_t count, size_t size);

Равно как и malloc выделит память под count объектов размером по size байт. Выделяемая память инициализируется нулями.

void * realloc (void *ptr, size_t size);

Перевыделяет (если может) память, на которую указывает ptr , в размере size байт. Если не хватает места для увеличения выделенной памяти, на которое указывает ptr , realloc создает новое выделение (аллокацию), копирует старые данные, на которые указывает ptr , освобождает старое выделение и возвращает указатель на выделенную память.

Если ptr равен NULL , realloc идентичен вызову malloc .

Если size равен нулю, а ptr не NULL , выделяется кусок памяти минимального размера, а исходная освобождается.

void * reallocf (void *ptr, size_t size);

Придумка из FreeBSD API. Как и realloc , но если не сможет перевыделить, очищает принятый указатель.

void * valloc (size_t size);

Как и malloc , но выделенная память выравнивается по границе страницы.

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

Статическое выделение памяти выполняется для всех глобальных и локальных переменных, имеющих явные описания в программе (без использования указателей). В этом случае механизм выделения памяти определяется расположением описания переменной в программе и спецификатором класса памяти в описании. Тип переменной определяет размер выделяемой области памяти, но механизм выделения памяти от типа не зависит. Имеется два основных механизма статического выделения памяти.

· Память под каждую из глобальных и статических (объявленных со спецификатором static) переменных выделяется до начала выполнения программы в соответствии с описанием типа. От начала до конца выполнения программы данные переменные связаны с выделенной для них областью памяти. Таким образом, они имеют глобальное время жизни, при этом область видимости у них различная.

· Для локальных переменных, объявленных внутри какого-либо блока и не имеющих спецификатора static, память выделяется другим способом. До начала выполнения программы (при её загрузке) выделяется довольно объёмная область памяти, называемая стеком (иногда используют термины стек программы или стек вызовов , чтобы сделать различие между стеком как абстрактным типом данных). Размер стека зависит от среды разработки, например, в MS Visual C++ по умолчанию под стек выделяется 1 мегабайт (это значение поддаётся настройке). В процессе выполнения программы при входе в определённый блок выделяется память в стеке для локализованных в блоке переменных (в соответствии с описанием их типа), при выходе из блока эта память освобождается. Данные процессы выполняются автоматически, поэтому локальные переменные в С++ часто называют автоматическими .

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

Использование термина "стек" объяснить легко – при принятом подходе к выделению и освобождению памяти переменные, которые помещаются в стек последними (это переменные, локализованные в самом глубоко вложенном блоке), удаляются из него первыми. То есть, выделение и освобождение памяти происходит по принципу LIFO (LAST IN – FIRST OUT, последним пришёл – первым вышел). Это и есть принцип работы стека. Стек как динамическую структуру данных и его возможную реализацию мы рассмотрим в следующем разделе.

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

Суммируя всё сказанное выше, можно представить следующую схему распределения памяти в процессе исполнения программы (рисунок 2.1). Расположение областей друг относительно друга на рисунке довольно условное, т.к. детали выделения памяти берёт на себя операционная система.

Рисунок 2.1 – схема распределения памяти

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

Для того, чтобы лучше понять проблему переполнения стека, советуем провести такой нехитрый эксперимент. В функции main объявите массив целых чисел размером, допустим, на миллион элементов. Программа скомпилируется, но при её запуске возникнет ошибка переполнения стека. Теперь добавьте в начало описания массива спецификатор static (или вынесите описание массива из функции main ) – программа заработает!

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

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