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

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

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

уже обсуждали. ищи

ответ: надо, т.к. завтра твоя программа будет частью большой системы 24x7

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

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

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

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

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

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

_U_>Ну, мыться тоже совершенно не обязательно. Ученые доказали: когда слой грязи достигает некоторой критической (и притом конечной) величины, он отваливается совершенно самостоятельно, и тело вновь становится чистым!

Ценю юмор.
А если серьёзно, есть что по теме сказать?

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

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

Уже сказали: http://rsdn.ru/forum/message/3071643.1.aspx

Автор: Сергей Мухин
Дата: 21.08.08

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

A>Сами они конечно "удалятся" при завершении программы (по крайней мере под Windows), куда же денутся.
A>Только не вызов деструктора плох не только утечкой памяти, но и утечкой других ресурсов (сокеты например).
A>В итоге получится очень путанный код — нужно будет помнить какие объекты владеют какими ресурсами, а какие нет.

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

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

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

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

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

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

СМ>ответ: надо, т.к. завтра твоя программа будет частью большой системы 24x7

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

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

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

СМ>>ответ: надо, т.к. завтра твоя программа будет частью большой системы 24x7

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

Вы упускаете мой текст! Вот он "уже обсуждали. ищи"

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

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

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

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

А вообще, переходи на C#.
Если тебе лень думать про время жизни объектов и не хочется этим управлять,
то языки с GC как раз для тебя.

alex-v wrote:

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

Тебе чего, лень две лишних строчки написать ?
Напиши, хуже не будет. И вообще, привыкай удалять всю память,
которую выделял.

> Нужно ли обязательно удалять объекты, созданные new?
Нужно.

Pzz wrote:

> Не обязательно, система подчистит. Если только деструкторы не делают

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

Ладно, извините, больше в тему писать не буду, а то опять пойдёт...

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

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

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

Pzz>Не обязательно, система подчистит. Если только деструкторы не делают нечто полезное во внешнем мире, что все-таки делать надо — ну, например, последнюю транзакцию на базе данных закрывают, содержимое файла из памяти на диск выкладывают.

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

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

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

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

A>>Сами они конечно "удалятся" при завершении программы (по крайней мере под Windows), куда же денутся.
A>>Только не вызов деструктора плох не только утечкой памяти, но и утечкой других ресурсов (сокеты например).
A>>В итоге получится очень путанный код — нужно будет помнить какие объекты владеют какими ресурсами, а какие нет.

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

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

Всем спасибо за ответы. Вообщем прихожу к выводу, что лучше удалять самому созданные объекты в «куче». Мне не сложно вставить несколько операторов delete.

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

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

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

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

AV>Всем спасибо за ответы. Вообщем прихожу к выводу, что лучше удалять самому созданные объекты в «куче». Мне не сложно вставить несколько операторов delete.

И открой для себя умные указатели типа boost::shared_ptr

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

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

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

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

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 не подчищает разве при потере связи с клиентом?

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

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

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

Ну это понятно. Венду, кстати, можно попросить удалить файл после закрытия. Я имел ввиду не столь тривиальные случаи. В унихе, например, SysV'кие IPC-объекты остаются жить после завершения процесса, их создавшего. Они не вполне потеряны для общества, в принципе, другой процесс может их открыть, т.е. у них по дизайну время жизни не ограничивается временем жизни процесса, и этим иногда пользуются. Но гораздо чаще процесс уходит, не подобрав за собой, а мусор в памяти ядра остается.

В венде я навскидку не назову аналогичного примера — наверное потому, что я ее хуже знаю

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

AV>Всем спасибо за ответы. Вообщем прихожу к выводу, что лучше удалять самому созданные объекты в «куче». Мне не сложно вставить несколько операторов delete.

Помещай динамический ресурсы под управление автоматических объектов (skope guard), тогда об этом не надо будет беспокоится.

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

СМ>а я вот пытаюсь создавать временные файлы с флагом delete_on_close (точное название см MSDN). И вроде хорошо получается.
1) Под семи системами?
2) А если тебе надо временный файл переоткрывать в процессе. Например, если ты в него пишешь, а потом создаёшь файл-мэпинги. Или пишешь в одном процессе, а используешь в другом?

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

Pzz>В венде я навскидку не назову аналогичного примера — наверное потому, что я ее хуже знаю
Ну можно дочерний процесс потерять, например

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

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

Ну 2 системы — это венда и унихи (для всех унихов существует одинаковое решение).

Просьба назвать остальные 5

E>2) А если тебе надо временный файл переоткрывать в процессе. Например, если ты в него пишешь, а потом создаёшь файл-мэпинги. Или пишешь в одном процессе, а используешь в другом?

Интересно, в каком из этих 2-х процессов деструктор должен удалять этот файл?

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

Pzz>>В венде я навскидку не назову аналогичного примера — наверное потому, что я ее хуже знаю
E>Ну можно дочерний процесс потерять, например

Это да, можно. Но чтобы обезопасить себя от такой потери в случае неожиданного падения родительского процесса, лучше бы сделать так, чтобы детишки сами позаботились о своем завершении в случае смерти папаши. Например, они могут держать с папашей открытий pipe. Если один конец пайпа закрылся, на другом могут считать, что кто-то умер.

К униху это тоже, кстати относится — там в случае смерти родительского процесса детишкам тоже ничего не говорят.

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

А>TerminateThread в помощь. Как минимум, стек потока освобождаться не будет.
Не совсем понятно что будет с этими "ликами" после завершения процесса.
Наводящий вопрос: В каком адресном пространстве будет находиться потерянная память?

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

Pzz>К униху это тоже, кстати относится — там в случае смерти родительского процесса детишкам тоже ничего не говорят.
Ну да. Но это только если детишки специальные какие-то. А если они не ухом ни рылом (скажем это какая-то командно-строчная утилита, например запускаемыйиз среды разработки тул), то фиг там плавал

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

СМ>>>а я вот пытаюсь создавать временные файлы с флагом delete_on_close (точное название см MSDN). И вроде хорошо получается.
E>>1) Под всеми системами?
Pzz>Ну 2 системы — это венда и унихи (для всех унихов существует одинаковое решение).
Pzz>Просьба назвать остальные 5
Это просто опечатка.
Я имел в виду, что под Win98 всё работает?

E>>2) А если тебе надо временный файл переоткрывать в процессе. Например, если ты в него пишешь, а потом создаёшь файл-мэпинги. Или пишешь в одном процессе, а используешь в другом?
Pzz>Интересно, в каком из этих 2-х процессов деструктор должен удалять этот файл?
Ну, например, есть какая-то процедура передачи владения. Скажем процесс, захватывая файл, переименовывает его.

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

Pzz>>К униху это тоже, кстати относится — там в случае смерти родительского процесса детишкам тоже ничего не говорят.
E>Ну да. Но это только если детишки специальные какие-то. А если они не ухом ни рылом (скажем это какая-то командно-строчная утилита, например запускаемыйиз среды разработки тул), то фиг там плавал

Командно-строчная утилита обычно все жа сама завершается, когда сделает свою работу.

Но вообще да, такая проблема существует. Можно написать отдельную маленькую програмку, которая занимается именно запусканием/прибиванием детишек, следит за состоянием папашки и сама при этом достаточно простая, чтобы не падать.

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

Pzz>>Ну 2 системы — это венда и унихи (для всех унихов существует одинаковое решение).
Pzz>>Просьба назвать остальные 5
E>Это просто опечатка.
E>Я имел в виду, что под Win98 всё работает?

Про девятку не знаю, но кому сейчас до нее есть дело?

Pzz>>Интересно, в каком из этих 2-х процессов деструктор должен удалять этот файл?
E>Ну, например, есть какая-то процедура передачи владения. Скажем процесс, захватывая файл, переименовывает его.

Она-то и будет основным источником потеряных файлов

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

Pzz>Про девятку не знаю, но кому сейчас до нее есть дело?
Ну их пока ещё есть.

Pzz>Она-то и будет основным источником потеряных файлов
Почему? Процесс источник попробует стереть файл, если он таки не переименуется, а процесс приёмник, если таки переименуется.
КТо-нибудь а сотрёт

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

Pzz>Она-то и будет основным источником потеряных файлов
Ещё оба могут пытаться тереть, кстати.

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

Pzz>>Она-то и будет основным источником потеряных файлов
E>Почему? Процесс источник попробует стереть файл, если он таки не переименуется, а процесс приёмник, если таки переименуется.
E>КТо-нибудь а сотрёт

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

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

Pzz>>Она-то и будет основным источником потеряных файлов
E>Ещё оба могут пытаться тереть, кстати.

Что автоматически означает нетривиальную синхронизацию в этом месте.

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

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

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

Есть ситуации когда сознательно не зовут delete ибо не надо.
Например объекты в memory pools. Вместо тучи деструкторов убивают сам pool. Apache runtime например активно использует эту технику.

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

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

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

Pzz>>>К униху это тоже, кстати относится — там в случае смерти родительского процесса детишкам тоже ничего не говорят.
E>>Ну да. Но это только если детишки специальные какие-то. А если они не ухом ни рылом (скажем это какая-то командно-строчная утилита, например запускаемыйиз среды разработки тул), то фиг там плавал

Pzz>Командно-строчная утилита обычно все жа сама завершается, когда сделает свою работу.

Pzz>Но вообще да, такая проблема существует. Можно написать отдельную маленькую програмку, которая занимается именно запусканием/прибиванием детишек, следит за состоянием папашки и сама при этом достаточно простая, чтобы не падать.

Я вот иногда замечаю что сам выполняю роль такого watchdog'a: сейчас вот uptime на рабочем компьютере уже 2600 часов. Был бы рад запустить программку и пускай она себе висит, только вот переодически кто-нибудь начинает отжирать(точнее не освобождать) память — приходится убивать и перезапускать. Хотя чаще просто слетают...
Одно время винамп частенько отладчиком из вечного цикла вытаскивал(хотя это была проблема аудиокодека), т.к. забываю playlist'ы сохранять, поэтому просто перезапускать не хотелось — потому как выбирать песенки снова — долго и лень...

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Я вот иногда замечаю что сам выполняю роль такого watchdog'a: сейчас вот uptime на рабочем компьютере уже 2600 часов. Был бы рад запустить программку и пускай она себе висит, только вот переодически кто-нибудь начинает отжирать(точнее не освобождать) память — приходится убивать и перезапускать. Хотя чаще просто слетают...
ЮЖ>Одно время винамп частенько отладчиком из вечного цикла вытаскивал(хотя это была проблема аудиокодека), т.к. забываю playlist'ы сохранять, поэтому просто перезапускать не хотелось — потому как выбирать песенки снова — долго и лень...

Да, вот так вот и работают современные системы 24x7...

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

S>Бывает так что вызов нескольких миллионов деструкторов значительно увеличивает время остановки сервера. Система сделает это быстрее.
Вы понимаете тот факт, что система (OS) не будт вызывать деструктор?
И вообще разницу между вызовом деструктора и освобождением памяти видите?

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

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

Pzz>>В венде я навскидку не назову аналогичного примера — наверное потому, что я ее хуже знаю
E>Ну можно дочерний процесс потерять, например

Ну, я могу и всю "венду" "потерять" — а если "правильно" написать сервера с клиентами вместе, то и всю сеть...

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

И>а зачем комп выключать виндовой кнопкой пуск? ведь после выключения питания вся память стирается, и никаких ликов не остается.

А некоторые системы именно так и выключаются: имеют "постоянно фиксированное состояние" и никакого shutdown-а им не нужно в принципе. Вопрос ведь как раз именно в том, что после выполнения полезной работы и получения всех результатов и сохранения оных и вообще — после всего этого "правильно" — "выключить и зачехлить инструмент, сложить все в коробку, а коробку отправить на 9-й склад" — просто потому, что инструмент у нас там лежит и в начале работы мы именно так его "доставали" — только в обратном порядке. Вот только с _программой_ ничего этого не нужно — программный инструмент все так же "находится на 9-м складе" и все так же готов к работе — в том числе и во время текущего задания. И в желании "сэкономить на уборке" — а точнее, "после работы просто отправить текущий инструмент в утиль и уничтожить его разом" — особенно если речь идет о "миллионе отдельных объектов", которые ни с чем "объективным" в системе не связаны и все как один "чисто виртуальны" — нами, собственно, в процессе работы и были созданы.

Или "уборка мусора" во всяких Java C# на пустом месте выдумана?

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

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

A>>Сами они конечно "удалятся" при завершении программы (по крайней мере под Windows), куда же денутся.
A>>Только не вызов деструктора плох не только утечкой памяти, но и утечкой других ресурсов (сокеты например).
A>>В итоге получится очень путанный код — нужно будет помнить какие объекты владеют какими ресурсами, а какие нет.

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

В винде глобальные Атомы, к примеру, не удалятся.

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

К>И вообще разницу между вызовом деструктора и освобождением памяти видите?

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

delete (obj_type*)obj:
1. call (obj_type::~obj_type(obj));
2. call (obj_type::delete(obj));

И даже если первый вызов бесплатный, второй занимает время (вызов системной функции или самописные махинации с указателями, накладные расходы на работу с объектами синхронизации и т.п.). Если не звать delete для всех выделенных объектов, можно на втором вызове как раз сэкономить.

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

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

Ну и пусть освободит память. Представьте себе работающий сервер, выделено несколько гигабайт памяти, миллионы объектов. И вот при остановке, когда все подсистемы завершили свою работу, сервер начинает хаотично ползать по этим гигабайтам, чтобы скинуть выделенные объекты в пулы, затем чистить сами пулы, отдавая системе забранную память. А оно вообще надо?

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

А как надо? Статически?

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

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

В принципе, иногда это может быть полезно. В C++ нет детерминированного порядка вызова деструкторов для статических объектов. Соответственно, если нужно гарантировать доступ к некоторой функциональности до самого окончания программы и система эти ресурсы и так почистит, то можно так делать. Но все-таки, это не очень хорошая практика. Например, всякие утилиты по поиску утечек памяти будут это дело находить и репортить.