Что считать утечкой памяти?

@ritmix10 · Регистрация: 04.02.2013

Студворк — интернет-сервис помощи студентам

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
class A
{
public:
    A() { cout << "create A" << endl; };
    ~A() { cout << "delete A" << endl; };
     void func(){ cout << "func A" << endl; };
 
private:
 
};
 
class B :public A
{
public:
    B() { cout << "create B" << endl; };
    ~B() { cout << "delete B" << endl; };
     void func(){ cout << "func B" << endl; };
 
private:
 
};
 
void main()
{
 
    A *a_ptr = new A;
    B b;
 
    a_ptr = &b;
 
    a_ptr->func();
}

Комментарий модератора

Выделил новую тему отсюда, т.к. оффтоп.

@hoggy · 21.06.2015, 13:43

Сообщение от Tulosba

Забить можно. Но это всё равно утечка. Что же ты непонятливый-то такой?

потому что это не утечка.

Кликните здесь для просмотра всего текста

Уте́чка па́мяти (англ. memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера, связанный с ошибками в работающих программах, вовремя не освобождающих ненужные уже участки памяти, или с ошибками системных служб контроля памяти.

в данном случае все контролируемо, ожидаемо, предсказуемо, и безвредно.

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

@ct0r · 21.06.2015, 14:07

hoggy, Википедия не является авторитетным источником. Или назовите мне автора этого определения. А то оно стремное какое-то. То есть если я напишу демон, который вообще не будет освобождать память, и скажу, что он контролируемо сжирает всю память ОС за 2 часа, после чего я его рестарчу, то типа у меня в демоне утечек памяти нет? А может все-таки это говорит о том, что там дофига утечек, но просто я на них забил?

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

Если мы пишем продакшен-код, то нужно спрашивать себя - "есть ли тут реальная причина не освобождать память"? Если причины нету, то освобождать. Обратные вопросы типа "а можно ли тут не освобождать память" - показатели непрофессионализма, до добра не доводящие.

@hoggy · 21.06.2015, 14:27

Сообщение от ct0r

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

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

если требования изменятся, и нужно будет, что бы демон 7/24 крутился без рестартов,
а он не может, потому что падает от нехватки памяти,
и хрен что с этим поделаешь, без серьёзного рефактора,
тогда это уже будет называться "утечки".

вот вам другой пример: есть специальные аппараты, и софтина под них.
требование к работе: утюг. воткнули в розетку - работает. выткнули - не работает.

в каких то частых циклах память освобождается,
как и должно быть по уму.

но долгоживущие объекты, аля "звуковая подсистема" создаются,
а на освобождение забивается.

зачем? время жизни - до конца приложения.
а выключение - дернуть шнур из розетки.

Сообщение от ct0r

Если мы пишем продакшен-код, то нужно спрашивать себя - "есть ли тут реальная причина не освобождать память"? Если причины нету, то освобождать. Обратные вопросы типа "а можно ли тут не освобождать память" - показатели непрофессионализма, до добра не доводящие.

верно.
однако, главный признак профессионализма - не делать то,
что можно было бы не делать.
то есть, не делать что-либо зазря.

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

мои софтинки это спокойно перенесли,
потому что я использовал смарт-поинтеры,
и вручную память нигде не дергал.
это к слову о продакшене.

а вот если кто нибудь докалебется до хэлловорлда из 5 строк кода:
так и хочется ответить: да идите в баню, оно вообще надо?
писать дополнительный код,
который не относится к иллюстрации момента,
и никому нафиг не нужен.

Tulosba · 21.06.2015, 14:44

Сообщение от hoggy

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

Чушь несёшь полнейшую. По твоей логике получается:
* Демон жрет память, мы это знаем, поэтому перезапускаем его каждые пару часов и радуемся. Утечек нет.
* Забыли перезапустить демона вовремя - утечки есть.
Так?

@maxillion · 21.06.2015, 14:59

Сообщение от hoggy

в данном случае все контролируемо, ожидаемо, предсказуемо, и безвредно.

Конечно для тебя это так , но это не справедливо для ТС . Поэтому для тех кто в курсе это не утечка, а для тех кто в танке да.

@ct0r · 21.06.2015, 15:18

hoggy, в статьях, документациях, инструментах обнаружения утечек, которые я видел, - везде это характеризуется как свойство именно кода, безотносительно каких-либо внешних требований. Можете привести ссылки какие-нибудь?

Сообщение от hoggy

а вот если кто нибудь докалебется до хэлловорлда из 5 строк кода:
так и хочется ответить: да идите в баню, оно вообще надо?
писать дополнительный код,
который не относится к иллюстрации момента,
и никому нафиг не нужен.

В целом тут вы правы, но фиг знает, может ТС был вообще не в курсе, что в программах надо освобождать память

Добавлено через 5 минут

Сообщение от hoggy

однако, главный признак профессионализма - не делать то,
что можно было бы не делать.
то есть, не делать что-либо зазря.

Еще более главный признак профессионализма - уметь понять, что именно зазря, а что нет

@hoggy · 21.06.2015, 20:01

Сообщение от Tulosba

Чушь несёшь полнейшую. По твоей логике получается:
* Демон жрет память, мы это знаем, поэтому перезапускаем его каждые пару часов и радуемся. Утечек нет.
* Забыли перезапустить демона вовремя - утечки есть.
Так?

сам по себе такой пример - ёрничание, передёргивание ситуации.
потому что никто в здравом уме не будет сознательно
писать настолько запредельный б_ы_д_л_о_к_о_д.

но если бы нашелся настоящий ценитель:
забыл бы перезапустить демона - поимел бы аварию сервиса.
а не утечку.

я вам приведу более реалестичный пример:

допустим, есть некий движок для видео-игр:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class engine
{
    system::window* mWindow;
    system::graphic* mGraphic;
    system::gui*       mGui;
    system::sound*   mSound;
 
   // нас не интересует весь код, только схематично конструктор :
   ... 
public:
    engine()
        :mWindow(new system::window(FULLSCREEN))
        ,mGraphic( new system::graphic(OPENGL,  mWindow->getWnd() ))
        ,mGUI( new system::gui(mWindow->getWnd() ))
        ,mSound()
   {
        try{
            mSound = new system::sound;
        }
        catch(const std::exception& e)
        {
            system::log << 
                "звуковая подсистема не работает\n"
                "причина: " << e.what() << "\n"
                "реакция: играем без звука\n";
        }
   }
 
   ~engine() {
      // здесь корректная остановка всех подсистем, 
      // и их деактивация
   }
};

собственно вопрос: может ли здесь быть утечка?
заметьте: я не спрашиваю, есть ли тут утечка,
я спрашиваю: теоретически вообще может ли здесь быть утечка?

Кликните здесь для просмотра всего текста

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

что с того, что у нас там не отработают диструкторы
отдельных полей класса в случае эксепшенов?

что с того, что часть памяти зачистит система, а не оператор delete ?

у нас в любом случае авария несовместимая с жизнью приложения.
мы все равно ничего не можем сделать.

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

в любом случае все, всё, что мы можем сделать в этой ситуации,
это заллогировать происшествие, и тихо помереть.

видео-игра без окна, без графики, без гуи функционировать все равно не сможет.

но для логгирования нам звать диструкторы не нужно.
мы это итак можем сделать.

и уже не важно кто зачистит за приложением: система, или диструкторы классов.
исход все равно один: это авария. а не утечка.

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

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

а без звуковой можно.
поэтому для неё персонально exception-safe

Добавлено через 8 минут

Сообщение от maxillion

Конечно для тебя это так , но это не справедливо для ТС . Поэтому для тех кто в курсе это не утечка, а для тех кто в танке да.

для тех кто в танке, утечки - это меньшее из их проблем.

Сообщение от ct0r

hoggy, в статьях, документациях, инструментах обнаружения утечек, которые я видел, - везде это характеризуется как свойство именно кода, безотносительно каких-либо внешних требований. Можете привести ссылки какие-нибудь?

могу только призвать к здравому смыслу.

вот вам очень простой способ:
вы сознательно выбросили объекты, или вы их потеряли?

@castaway · 21.06.2015, 20:04

Ребят, а существует ли какое-то одно конкретное трактование понятия "утечка памяти"? Если да, тогда откуда растут корни?
А может быть всё намного проще, и каждый прав по-своему!?

@hoggy · 21.06.2015, 20:07

Сообщение от castaway

Если да, тогда откуда растут корни?

"неконтролируемая утеря ресурсов" жеж.

@castaway · 21.06.2015, 20:17

Сообщение от hoggy

"неконтролируемая утеря ресурсов" жеж.

Ок. Уточним. Откуда растут корни этого выражения?

@hoggy · 21.06.2015, 20:27

Сообщение от castaway

Откуда растут корни этого выражения?

а хз, это что-то из области истории.

@castaway · 21.06.2015, 20:31

Сообщение от hoggy

а хз, это что-то из области истории.

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

Tulosba · 21.06.2015, 22:17

Сообщение от castaway

Пусть каждый трактует это понятие полагаясь на собственные убеждения.

Ага. А потом договоримся до того, что один прав, когда 2+2=5, а другой - когда 2*2 = 6.

Определение утечки памяти - одно единственное: отсутствие возможности освободить память объекта, доступ к которому невозможен.
(Не знаю даже какой авторитетности должен быть источник, чтобы в это поверил наш неверующий Фома).

Считать утечки существенными или нет - совершенно другой разговор (то, что пытается впарить нам hoggy). Важность утечки никоим образом не отменяет факта существования самой утечки.

Если вдруг возникло какое-то сомнение - запусти профайлер, заточенный на поиск утечек и посмотри, что он будет говорить например для такого кода (с delete и без):

C++
1
2
3
4
int main() {
   int* p = new int;
   // delete p;
}

А говорить он будет (без delete), совершенно однозначно, что утечки есть, потому что ему безразлично важные они или нет (он не такой как hoggy).
Вариант вывода valgrind'а:

4 bytes in 1 blocks are definitely lost in loss record 1 of 1

@castaway · 21.06.2015, 22:21

Сообщение от Tulosba

Ага. А потом договоримся до того, что один прав, когда 2+2=5, а другой - когда 2*2 = 6.

Ну это ты уже немного перегнул

@hoggy · 21.06.2015, 22:22

Сообщение от Tulosba

Определение утечки памяти - одно единственное: отсутствие возможности освободить память объекта, доступ к которому невозможен.
(Не знаю даже какой авторитетности должен быть источник, чтобы в это поверил наш неверующий Фома).

хотя бы один любой источник аля "виккипедия" приведите.
потому что везде пишут: неконтролируемая утеря ресурса.

@castaway · 21.06.2015, 22:23

Не по теме:

Tulosba, я что-то не понял, они всё-таки добавили кнопку "Выделить код", или я неосознанно скрипт установил?

@hoggy · 21.06.2015, 22:24

Сообщение от Tulosba

Если вдруг возникло какое-то сомнение - запусти профайлер, заточенный на поиск утечек и посмотри, что он будет говорить например для такого кода (с delete и без):

запустил.
правда настроил так, что бы он не агрился на эту переменную.
и блин... молчит, зараза.

или вот: запилил сингелтон, который майн пережил - сагрилсо!

вот не нада вот такую туфту прогонять.

я аппелирую к здравому смыслу.

вы - к форме, не учитывая содержание.

Tulosba · 21.06.2015, 22:31

Сообщение от hoggy

неконтролируемая утеря ресурса.

Так а ты думаешь забытый вызов delete не есть неконтролируемая утеря ресурса?
Контроль подразумевает возможность что-то сделать (освободить память в данном случае), а возможности этой нет на уровне языка. И не надо тут про ОС повторять. ОС это уже другой уровень, которого, как я раньше говорил, может и вовсе не быть.

Не по теме:

Сообщение от castaway

Ну это ты уже немного перегнул

Лиха беда начало.

Tulosba · 21.06.2015, 22:34

Не по теме:

Сообщение от castaway

я что-то не понял, они всё-таки добавили кнопку "Выделить код", или я неосознанно скрипт установил?

А я уже хотел жаловаться на баг в скипте :D, у меня двойной вариант рисует:

Если включили, то это круто, и юзерскрипт я конечно тогда отключу.

@hoggy · 21.06.2015, 22:39

Сообщение от Tulosba

Так а ты думаешь забытый вызов delete не есть неконтролируемая утеря ресурса?

разумеется я так не думаю.
ключевое слово "забытый".

Сообщение от hoggy

вот вам очень простой способ:
вы сознательно выбросили объекты, или вы их потеряли?

Сообщение от Tulosba

Контроль подразумевает возможность что-то сделать

ага. и сделать это можно разными способами.

Сообщение от Tulosba

ОС это уже другой уровень, которого, как я раньше говорил, может и вовсе не быть.

вот если его нету - тогда это уже другой разговор.

обратите внимание:

Сообщение от ritmix10

void main()

100% что это вижал студия, так что не нада тут ля ля.

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

Новые блоги и статьи Все статьи Все блоги /
[golang] Двоичная куча, min-heap alhaos 20.05.2026 Двоичная куча Двоичная куча — структура данных, которая всегда держит самый важный элемент наготове. Представьте очередь к хилеру в игре, и очередь из игроков в приоритете те у кого меньше. . .	[golang] Breadth-First Search alhaos 19.05.2026 BFS (Breadth-First Search) — это базовый алгоритм обхода графа в ширину, который поуровнево исследует все связанные вершины. Он начинает с выбранной точки и проверяет всех соседей, прежде чем. . .	[golang] Алгоритм «Хак Госпера» alhaos 17.05.2026 Алгоритм «Хак Госпера» Хак Госпера (Gosper's Hack) — алгоритм нахождения следующего по величине числа с тем же количеством установленных бит. Придуман Биллом Госпером в 1970-х, опубликован в. . .	Рисование бинарного древа до 6-го колена на js, svg. russiannick 17.05.2026 <svg width="335" height="240" viewBox="0 0 335 240" fill="#e5e1bb"> <style> <!]> </ style> <g id="bush"> </ g> </ svg> function fn(){ let rost;/ / высота древа let xx=165,yy=210,w=256;
FSharp: interface of module DevAlt 16.05.2026 Интерфейс модуля F# позволяет управлять доступностью членов, содержащихся в реализации модуля. По-умолчанию все члены модуля доступны: module Foo let x = 10 let boo () = printfn "boo" . . .	Хитросплетение родственных связей пантеона греческих богов. russiannick 14.05.2026 Однооконник, позволяющий узреть и изучить отдельных героев древней Греции. <!DOCTYPE html> <html lang="ru"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible". . .	[golang] Угол между стрелками часов alhaos 12.05.2026 По заданным значениям часа и минуты необходимо определить значение меньшего угла между стрелками аналогового циферблата часов. import "math" func angleClock(hour int, minutes int) float64 { . . .	Debian 13: Установка Lazarus QT5 ВитГо 09.05.2026 Эта инструкция моя компиляция инструкций volvo https:/ / www. cyberforum. ru/ blogs/ 203668/ 10753. html и его же старой инструкции по установке Lazarus с gtk2. . .

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	21.06.2015, 14:07
	hoggy, Википедия не является авторитетным источником. Или назовите мне автора этого определения. А то оно стремное какое-то. То есть если я напишу демон, который вообще не будет освобождать память, и скажу, что он контролируемо сжирает всю память ОС за 2 часа, после чего я его рестарчу, то типа у меня в демоне утечек памяти нет? А может все-таки это говорит о том, что там дофига утечек, но просто я на них забил? У нас в памяти есть объект, который оттуда нельзя удалить. Приложение само не освобождает память, в которой больше не нуждается для работы, а возлагает это на ОС. Поэтому в приложении - по определению это утечка. Осознанная или нет, допустимая или нет, - это уже другой вопрос. Если мы пишем продакшен-код, то нужно спрашивать себя - "есть ли тут реальная причина не освобождать память"? Если причины нету, то освобождать. Обратные вопросы типа "а можно ли тут не освобождать память" - показатели непрофессионализма, до добра не доводящие. 0

@castaway 4986 / 3093 / 456 Регистрация: 10.11.2010 Сообщений: 11,170 Записей в блоге: 10
	21.06.2015, 20:04
	Ребят, а существует ли какое-то одно конкретное трактование понятия "утечка памяти"? Если да, тогда откуда растут корни? А может быть всё намного проще, и каждый прав по-своему!? 0

@castaway
	21.06.2015, 22:23
	Не по теме: Tulosba, я что-то не понял, они всё-таки добавили кнопку "Выделить код", или я неосознанно скрипт установил? 0