int main()
{
int * i = new int(5);
i = new int(10);
}

Здравствуйте, MShura, Вы писали:


А>>Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает?

MS>Можно простейший пример, показывающий лики памяти на win32?

Здравствуйте, wo1and, Вы писали:

int main()
{
int * i = new int(5);
i = new int(10);
}

И что же с нашей программой и с памятью происходит после последней фигурной скобочки?

W>

W>int main()
W>{
W>int * i = new int(5);
W>i = new int(10);
W>}
W>

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

Здравствуйте, alex-v, Вы писали:

AV>А если серьёзно, есть что по теме сказать?

Ну, если по теме, то. Представим ситуацию — нашы объекты создают COM-объекты в каком-нибудь local COM server (или remote COM server), и в деструкторе вызывают им Release(). И если не делать delete на нашей стороне, то после завершения нашей проги в указанном сервере останутся болтаться куча потерянных объектов.

Ну, и еще подобных примеров кучу придумать можно.

Здравствуйте, _Ursus_, Вы писали:

_U_>Ну, и еще подобных примеров кучу придумать можно.

Куча примеров — это запросто! Ком-объекты отдельно — локальные отдельно.

А>>Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает?

MS>Можно простейший пример, показывающий лики памяти на win32?

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

Здравствуйте, MShura, Вы писали:


А>>Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает?

MS>Можно простейший пример, показывающий лики памяти на win32?

Пример не приведу — не охота перегружаться потом Думаю, если выделить побольше, то диспетчер задач покажет.
Видел как прога за собой около 120 метров оставляла.

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

А>>>Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает?

W>MS>Можно простейший пример, показывающий лики памяти на win32?

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

Вопрос был задан в контексте топика:

alex-v:

Обязательно ли надо перед закрытием программы удалять объекты из памяти, созданные с помощью new ? Может они сами атоматически удаляются и память высвобождается, а?

Pzz:

Не обязательно, система подчистит.

— Anonim 361:

Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает

— Я:

Можно простейший пример, показывающий лики памяти на win32

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

Pzz>>>Однако если это все-таки делать, и кроме того, добавить в программу счетчик зааллоцированных, но не освобожденных объектов, получите встроенную самодиагностику утечек памяти, а это многого стоит.
А>>Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает?
А>А как вы нашли лики в закрытой программе?

закрытая программа это термин такой? не сталкивался

MS>>Можно простейший пример, показывающий лики памяти на win32?

А>Пример не приведу — не охота перегружаться потом Думаю, если выделить побольше, то диспетчер задач покажет.
А>Видел как прога за собой около 120 метров оставляла.
Попробуйте привести пример, который можно повторить, а не кто-то где-то чего-то видел.

А>И тогда вопрос, зачем ведётся такая борьба с утечками памяти.. неужели все серваки пишут..
Пока программа работает утечки памяти в программе приводят к необратимым (на время жизни программы) потерям.

В драйверах действительно можно нагадить и уже никто за тобой не приберёт.

Здравствуйте, sokel, Вы писали:

S>Здравствуйте, alex-v, Вы писали:

AV>>Обязательно ли надо перед закрытием программы удалять объекты из памяти, созданные с помощью new ? Может они сами атоматически удаляются и память высвобождается, а?

S>Бывает так что вызов нескольких миллионов деструкторов значительно увеличивает время остановки сервера. Система сделает это быстрее.

У вас каша в голове. Система деструкторы не вызовет. Она просто освободит память.

S> А для отладки утечек можно освобождать под #ifdef _DEBUG. Как пример — stateless блочный аллокатор — чтобы освободить выделенные блоки нужно хранить их список. Заполнение списка и освобождение памяти можно сделать это под #ifdef _DEBUG, заодно при очистке проверяя на 0 количество отданных объектов.

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

Здравствуйте, Сергей Мухин, Вы писали:

S>>Бывает так что вызов нескольких миллионов деструкторов значительно увеличивает время остановки сервера. Система сделает это быстрее.

СМ>У вас каша в голове. Система деструкторы не вызовет. Она просто освободит память.

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

ЗЫ: сам размышляю над таким "кастомным манагером памяти" — есть куча выделений по ходу загрузки и обработки данных и вывода результатов на диск и в БД — после чего все эти "выделения" никому не нужны вообще и не важно кто их там убъет и в каком порядке, зато ресурсы процессора критичны. БД, само собой, закрывать отдельно.

S>> А для отладки утечек можно освобождать под #ifdef _DEBUG. Как пример — stateless блочный аллокатор — чтобы освободить выделенные блоки нужно хранить их список. Заполнение списка и освобождение памяти можно сделать это под #ifdef _DEBUG, заодно при очистке проверяя на 0 количество отданных объектов.

СМ>убивать надо таких программистов, которые пишут программы с несколькими миллионами динамически аллокированных объектов.

Ты ап чем?

Здравствуйте, Pzz, Вы писали:

Pzz>Сокеты тоже удаляются. Вообще, есть не так уж и много объектов, которые система не подчищает за завершившейся программой. В венде я навскидку не назову ни одного, в унихе парочку назову.

Напрмиер, неудалённые временные файлы...

Здравствуйте, Erop, Вы писали:


E>Напрмиер, неудалённые временные файлы...

а я вот пытаюсь создавать временные файлы с флагом delete_on_close (точное название см MSDN). И вроде хорошо получается.

Здравствуйте, MShura, Вы писали:

MS>Можно простейший пример, показывающий лики памяти на win32?

TerminateThread в помощь. Как минимум, стек потока освобождаться не будет.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>Уже было длинное обсуждение в точности на эту тему, Извините, что не привел ВСЕ сообщения. Ищите сами!

Зачем? Если хотите подискутировать, то изложите свои доводы. Совета же я не спрашивал и свое мнение имею. Так что ищет пусть тот, кому нужен совет.

Здравствуйте, MasterZiv, Вы писали:

MZ>ОБЯЗАТЕЛЬНО ! Ты готов поручиться, что все на свете операционки, где
MZ>реализован какой-то компилятор С++, освобождают память приложения
MZ>при окончании последнего ? Если не готов (а я в этом уверен), то
MZ>и нечего было говорить.

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

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

Здравствуйте, Аноним, Вы писали:

Pzz>>Однако если это все-таки делать, и кроме того, добавить в программу счетчик зааллоцированных, но не освобожденных объектов, получите встроенную самодиагностику утечек памяти, а это многого стоит.

А>Я вот одного не пойму — откуда лики памяти берутся, если система сама всё подчищает?

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

Здравствуйте, alzt, Вы писали:

A>Если и сокеты закрываются, то
A>на вскидку — отправить серверу "goodbuy" по прикладному протоколу.
A>Без этого гудбай сервер очень обижается.
A>Ситуация правда достаточно экзотичная.

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

Здравствуйте, _Ursus_, Вы писали:

_U_>Ну, если по теме, то. Представим ситуацию — нашы объекты создают COM-объекты в каком-нибудь local COM server (или remote COM server), и в деструкторе вызывают им Release(). И если не делать delete на нашей стороне, то после завершения нашей проги в указанном сервере останутся болтаться куча потерянных объектов.

А COM не подчищает разве при потере связи с клиентом?