@newbie777

Не скажу за все ОС-и, но под Windows есть менеджер памяти. Когда по ходу кода встречается new, ну или что - то другое для алокации динамической памяти из кучи, менеджер памяти всё это дело конечно же отследит и при закрытие процесса он всю это память корректно освободит.

Вопрос, зачем для объектов, созданных посредствам new, следует вызывать delete в деструкторе, если за вас это сделает менеджер памяти ОС ?

0

@CheshireCat

Да-да-да. Ты и в самом деле никогда не слыхал о программах, постоянно динамически создающих тысячи и тысячи этих самых "объектов" и работающих в режиме 365х7х24 (365 дней в году, 7 дней в неделю, 24 часа в сутки)?

0

@daslex

Ты начал учить не с самого главного. Зачем по твоему return 0 нужен?
Неужели думаешь, что в 100% из множества случаев в течении долгих лет любая программа всегда завершится корректно?

0

@newbie777

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

Что бы вернуть ноль.
Не думаю.

0

@CheshireCat

Нннуууу..... Строго говоря, да, когда процесс завершается, его адресное пространство освобождается. Но:
- во-первых, с моей точки зрения, хороший тон в программировании предписывает соблюдение принципа "нагадил - убери за собой!",
- во-вторых, объекты могут "держать" не только память, но и какие-нибудь ограниченные ресурсы,
- в-третьих, а кто может дать гарантию, что твой код никогда больше не будет дорабатываться или масштабироваться другим программистом? Если пишешь исключительно для себя, любимого, то можно. А в промышленном программировании сплошь и рядом бывает, что код дорабатывается и изменяется другими программистами, иногда через годы после написания его автором.

Ну и так далее.... К тому же, в современном C++ использование RAII позволяет вообще забыть о "ручном" управлении new/delete. Я уж и не помню, когда мне приходилось лечить утечки памяти, - лет этак восемь-десять назад, подчищая код, доставшийся мне в наследство от других программистов....

1

@newbie777

Не, ну что значит забыть или не забыть. Любая более менее серьёзная программа вдоль и поперёк усеяна указателями и лично они у меня повсюду участвуют в бизнес логике, даже не представляю, как можно без ручного управления памятью хоть что - то написать, так, разве что хелоу ролд на смартпоинтерах.
У меня везде указатели летают между потоками, идут проверки на нули (при удаления nullptr присваиваю) и тд, как без указателей вообще грамотно синхронизировать данные в потоках .... (особенно если ты придерживаешься парадигмы non blocking или event driven программирования )

P.S.: я не новичок, несмотря на ник, мне просто в данной теме было интересно, во всех ли ОСях менеджер памяти корректно почистит за тобой ...

0

@Fulcrum_013

Даже в винде существуют Common области памяти которые вообще ни за каким процессом не числятся. Мало того если распределение было в Common области которая числится не за твоим процессом то оно там и останется. А так да - у всех осей (во всяком случае у тех с которыми имел дело, даже Siemens R-300-16 70-ых годов) обычно блоки памяти числится за процессом (у многих еще и открытые файлы и т.п.), и по завершении процесса все освобождается/закрывается. Опять же распределение памяти через New и менеджер памяти оси пересекаются мало и далеко не во всех осях/менеджерах/режимах менеджера процесса. Обычно менеджер кучи процесса отгрызает кучу блоками через вызовы менеджера ОС, а за выделением/освобождением внутри блоков следит сам. А то накладные расходы не ве....ться в поворот. Даже под доской память средствами ОС распределялась параграфами по 16 байт причем на каждый блок дескриптор в параграф, соответственно есть смысл брать память у оси кусками побольше. Ну и если в дескрипторе переписать ProcessId 0 он вообще не удалится.

1

@Fulcrum_013

На С++ то же не помню. Хотя пользую ручное управление памятью. А вот на паскале... не далее чем неделю назад со всеми этими смарт-поинтерами утечка и полезла. переделал с дельфовских class котоые со смарт-поинтерами на object которые с ручным управлением - и проблема исчезла как ее и не было.

0