Здравствуйте, 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) не будт вызывать деструктор?
И вообще разницу между вызовом деструктора и освобождением памяти видите?

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