В чем заключается проблема, связанная с оператором new? На самом деле эта проблема порождается операторами new и delete, использованными вместе. Рассмотрим результат следующей последовательности размещений и удалений объектов.
Message* get_input(Device&); // создаем объект класса Message
// в свободной памяти
while(/* . . . */) {
Message* p = get_input(dev);
// . . .
Node* n1 = new Node(arg1,arg2);
// . . . delete p;
Node* n2 = new Node (arg3,arg4);
// . . .
}
Каждый раз, выполняя этот цикл, мы создаем два объекта класса Node, причем в процессе их создания возникает и удаляется объект класса Message.
Также вам может показаться, что такая тема как http://www.brit-r.ru/products/mastics/mastic-road/ никак не связана и даже не тематична с программированием. Хотя, может быть и связана.
В любом случае все-таки зайдите на сайт brit-r.ru
Тема дорожно климатические зоны там представлена весьма широко. На том сайте можно узнать много интересного на тему дорожно климатические зоны
Что означает вообще тема дорожно климатические зоны, где найти тему дорожно климатические зоны - про это написано на сайте brit-r.ru
Это очень важная для многих людей тема - дорожно климатические зоны Спасибо сайту brit-r.ru за информацию на тему дорожно климатические зоны
Такой фрагмент кода вполне типичен для структур данных, используемых для ввода данных, поступающих от какого-то устройства. Глядя на этот код, можно предположить, что каждый раз при выполнении цикла мы тратим 2*sizeof(Node) байтов памяти (плюс расходы свободной памяти). К сожалению, нет никаких гарантий, что наши затраты памяти ограничатся ожидаемыми и желательными 2*sizeof(Node) байтами. В действительности это маловероятно.
Представим себе простой (хотя и вполне вероятный) механизм управления памятью. Допустим также, что объект класса Message немного больше, чем объект класса Node. Эту ситуацию можно проиллюстрировать следующим образом: темно-серым цветом выделим память, занятую объектом класса Message, светло-серым — память, занятую объектами класса Node, а белым — “дыры” (т.е. неиспользуемую память).
Итак, каждый раз, проходя цикл, мы оставляем неиспользованную память (“дыру”). Эта память может составлять всего несколько байтов, но если мы не можем использовать их, то это равносильно утечке памяти, а даже малая утечка рано
После создания объекта п1 (один объект Message и один объект Node)
После удаления объекта р (одна “дыра” и один объект Node)
После создания объекта п2 (два объекта класса Node и маленькая “дыра”)
После создания объекта п1 во второй раз
После создания объекта п2 во второй раз
После создания объекта п2 в третий раз
или поздно выводит из строя долговременные системы. Разбиение свободной памяти на многочисленные “дыры”, слишком маленькие для того, чтобы в них можно было разместить объекты, называется фрагментацией памяти (memory fragmentation). В конце концов, механизм управления свободной памятью займет все “дыры”, достаточно большие для того, чтобы разместить объекты, используемые программой, оставив только одну “дыру”, слишком маленькую и потому бесполезную. Это серьезная проблема для всех достаточно долго работающих программ, широко использующих операторы new и delete; фрагментация памяти встречается довольно часто. Она сильно увеличивает время, необходимое для выполнения оператора new, поскольку он должен выполнить поиск подходящего места для размещения объектов. Совершенно очевидно, что такое поведение для встроенной системы недопустимо. Это может также создать серьезную проблему в небрежно спроектированной невстроенной системе.
Почему ни язык, ни система не может решить эту проблему? А нельзя ли написать программу, которая вообще не создавала бы “дыр” в памяти? Сначала рассмотрим наиболее очевидное решение проблемы маленьких бесполезных “дыр” в памяти: попробуем переместить все объекты класса Node так, чтобы вся свободная память была компактной непрерывной областью, в которой можно разместить много объектов.
К сожалению, система не может этого сделать. Причина заключается в том, что код на языке С++ непосредственно ссылается на объекты, размещенные в памяти. Например, указатели n1 и n2 содержат реальные адреса ячеек памяти. Если мы переместим объекты, на которые они указывают, то эти адреса станут некорректными. Допустим, что мы (где-то) храним указатели на созданные объекты.
Мы могли бы представить соответствующую часть нашей структуры данных следующим образом.
Теперь мы уплотняем память, перемещаем объекты так, чтобы неиспользуемая память стала непрерывным фрагментом.
Опубликовал katy
April 25 2015 09:50:19 ·
0 Комментариев ·
2555 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
