Не подскажите что произойдёт если написать new int; и нигде

не сохранять указатель? Утечка памяти?

Утечка

А что значит "утечка"? Типа память будет считаться выделенной, и поэтому будет "висеть пустой"?

Выделится блок памяти, но освобождён не будет

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

Ну в нем то всё равно что-то лежать будет Ни один блок памяти пустым не бывает

Я про то, что там не будет никаких данных пользователя, будет лежать "мусор"

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

так

Ага. А в УК статья какая? 404 или иная?

404 - отсутсвие статьи?

Ну типа)

Да вот, напрямую статья есть http://www.consultant.ru/document/cons_doc_LAW_10699/a4d58c1af8677d94b4fc8987c71b131f10476a76/

Очень тонко. Я так тонко не понимаю. В чём опасность выделения памяти и её неиспользования?

ты серьёзно спрашиваешь или по приколу?

Серьёзно. Я не шарю настолько. Для меня сейчас такая утечка памяти - оплошность и не более.

Это так и есть. Но представь, что у тебя не учебная программа, а программа (скажем) управления движением самолёта, и в ней таких оплошностей не одна, а в каждой функции, которых, скажем, 5000. Далее, эта утечка в 4-8 байт (больше на самом деле), конечно, маленькая, и незаметная. Но представь, что у тебя в твоей этой большой программе с 5000ми маленьких утечек есть одна утечка памяти посерьёзнее, размером, скажем, в мегабайт. Теперь всю ситуацию представь целиком. У тебя огромный программный комплекс, в нём 5001 утечка памяти, и одна из них - очень большая и критическая. РАЗБИРАЙСЯ!

Вот поэтому и не бывает несерьёзных утечек памяти

Честно говоря, всё равно не очень понимаю. В какой момент это становится проблемой? При очередном, например, динамическом выделении памяти из кучи? То есть, когда в куче нет необходимого объёма памяти для текущего динамического выделения из-за таких утечек?

Ты понимаешь, как ищутся в программах утечки памяти ?

Нет

@pref_prof, на бортовом компьютере самолёта закончится память, придёт страшный OOM Killer и убьёт систему управления полётом как слишком обнаглевшую. А если не придёт — программа сама перепишет часть своих внутренних управляющих структур из-за переполнения и контроль над самолётом будет потерян. В обоих случаях вам вполне реально грозит УК РФ

Ну чести ради, вроде на таких штуках запрещены же динамические аллокации?

Создаётся большой список всех динамических объектов программы, куда помещается каждый создаваемый динамически объект (по факту каждый выделенный блок памяти) При уничтожении объекта он, наоборот, удаляется из этого списка. По окончании программы мы можем распечатать этот список, если он не пустой, и подумать, где каждый блок был выделен (обычно эта информация сохраняется при создании объекта) и где он должен был быть освобождён, но не был освобождён.

Необходимости контроля и понимания это не отменяет. Если и запрещены — наверное, это одна из важных причин запрета

Не знаю совсем

Это совершенно другой вопрос. Иногда и не запрещены.

Ок. А как программа может сама себя "перезаписать"? Я понимаю, что такое может произойти, если криво на Asm-е писать (не под ОС); в C, думал, это отслеживается компилятором. Или, по крайней мере, системой, если она есть.

У человечества вообще не так уж много инструментов для борьбы с утечками и инспекции динамической памяти. Поэтому вместо того, чтобы искать в лесу допустимых утечек недопустимые, проще не допускать их вообще.

В большинстве современных ОС это невозможно. А вот в DOS - запросто.

Что значит перезаписать себя?

Если система есть — придёт кто-то и убьёт программу. Просто потому что ей дальше некуда писать свои данные. Если системы нет — программа всевластна. Ну вот что будет, если записать память по адресу большему, чем у нас всего памяти? Никто не знает и не отвечает на этот вопрос — программа может начать писать в начало доступного диапазона памяти, а может записать "вникуда" так, что эти данные (критические в нашем случае!) потом никто не сможет прочесть, может вылететь сама матрица с ошибкой

"программа сама перепишут часть своих внутренних управляющих структур". Я это понял так: программа, записывая и неконтролируемо сжирая память, может "затереть" себя в ОЗУ.

Бред какой то, к с++ не имеющий тем более отношения

Тогда как понимать "программа сама перепишут часть своих внутренних управляющих структур"?

Как правило затирается не код, а стек.

Ну и если в стеке был записан адрес выхода из функции, то всё накроется медным тазом. Я это и представлял, когда писал. Неправильно выразился. Прошу простить

А вот мне тоже стало интересно Каким же это образом? Рано или поздно аллокатор начнет bad_alloc бросать Собственно, современные ОС вряд ли хипу на стек пустят

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

код секция мапится в страничку которую нельзя менять из юзерйспейса, ничего он не затирается

Это если у вас на системе есть юзерспейс и средства менеджмента памяти....

как хорошо, что есть апи, которые позволяют +W сделать

ну это как выстрел по ноге самому себе

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