разрушение объектов, оно надо? и если да, то как
имеем:
void __fastcall TForm1::f()
{
TStringList *MyList = new TStringList;
...
}
вопрос:
нужно ли в конце ф-ции уничтожать MyList и если нужно, как это сделать грамотно? Вопрос чисто спортивный, никогда этим не занимался и жил хорошо, а вот тут задумался, я лично думаю, что MyList умрет самостоятельно и так, без посторонней помощи, но вдруг нет.
RE:убедительная просьба не кидать тухлыми помидорами
void __fastcall TForm1::f()
{
TStringList *MyList = new TStringList;
...
}
вопрос:
нужно ли в конце ф-ции уничтожать MyList и если нужно, как это сделать грамотно? Вопрос чисто спортивный, никогда этим не занимался и жил хорошо, а вот тут задумался, я лично думаю, что MyList умрет самостоятельно и так, без посторонней помощи, но вдруг нет.
RE:убедительная просьба не кидать тухлыми помидорами
Умрет он самостоятельно или нет одному богу известно. А программист должен всеже быть уверен в этом. Потому правилом хорошего тона, да и необходимостью в большинстве случаев, является использование delete после каждого new.
Цитата:
Originally posted by moonmike
Умрет он самостоятельно или нет одному богу известно. А программист должен всеже быть уверен в этом. Потому правилом хорошего тона, да и необходимостью в большинстве случаев, является использование delete после каждого new.
Умрет он самостоятельно или нет одному богу известно. А программист должен всеже быть уверен в этом. Потому правилом хорошего тона, да и необходимостью в большинстве случаев, является использование delete после каждого new.
А как он можут умереть самостоятельно?
Самоуничтожение?
Цитата:
Originally posted by Green
А как он можут умереть самостоятельно?
Самоуничтожение?
А как он можут умереть самостоятельно?
Самоуничтожение?
Ну StringList не умрет, но большинство контролов/компонентов VCL умрут вместе со своим владельцем, вернее должны умереть.Так что рекомендация носит общий характер.
Цитата:
Originally posted by moonmike
Ну StringList не умрет, но большинство контролов/компонентов VCL умрут вместе со своим владельцем, вернее должны умереть.Так что рекомендация носит общий характер.
Ну StringList не умрет, но большинство контролов/компонентов VCL умрут вместе со своим владельцем, вернее должны умереть.Так что рекомендация носит общий характер.
Т.е. если объект агрегирован в некий объект-владелец целиком или агрегирован через указатель и владелец уничтожает его в своем деструкторе.
Но тут ни о какой агрегации не идет речи, и если TStringList не обладает самоуничтожением по некоторому событию (что само по себе некорректно), то налицо утечка памяти.
void __fastcall TForm1::f()
{
TStringList *MyList = new TStringList;
...
}
Цитата:
Originally posted by Green
Т.е. если объект агрегирован в некий объект-владелец целиком или агрегирован через указатель и владелец уничтожает его в своем деструкторе.
Но тут ни о какой агрегации не идет речи, и если TStringList не обладает самоуничтожением по некоторому событию (что само по себе некорректно), то налицо утечка памяти.
void __fastcall TForm1::f()
{
TStringList *MyList = new TStringList;
...
}
Т.е. если объект агрегирован в некий объект-владелец целиком или агрегирован через указатель и владелец уничтожает его в своем деструкторе.
Но тут ни о какой агрегации не идет речи, и если TStringList не обладает самоуничтожением по некоторому событию (что само по себе некорректно), то налицо утечка памяти.
void __fastcall TForm1::f()
{
TStringList *MyList = new TStringList;
...
}
Вчитайся плиз в первоначальный вопрос. Автор топика интересуется принципиальной необходимостью применения delete. В приведенном им примере delete необходим, в ряде случаев
Цитата:
если объект агрегирован в некий объект-владелец целиком или агрегирован через указатель и владелец уничтожает его в своем деструкторе.
необходимым он не является.
Потому я и дал общую рекомендацию в первом своем ответе.
ну вы тут некисло разошлись, тогда встречный вопрос, в данном примере MyList - агрегированный объект?
RE: как бы это опять же грамотно сказать то, в самом простом примере есть некое пространство
{
int i=0;
...
}
и в нем мы объявили i, если последить за переменной i в пошаговом режиме, то когда мы выйдем за пределы пространства - i станет не определено, (для MyList тоже самое), а вопрос в том, что подразумевает ли то что данная переменная уже не определена то что она была уже уничтожена. Почитаю лучше БС на эту тему, хотя там наверное все просто а-ля: компилятор компилятором, сделал переменную - убей переменную, но это же занудство на самом деле, просто нужно разобраться какие способы выделения памяти красиво обрабатываются компилятором, а какие нет. Кроме new и delete есть еще операторы выделения и очистки памяти(причем кажись они все парные), и если хотя бы одна такая пара обрабатывается некорректно, т.е. память выделили, а очистить забыли, приложение закрылось, а в памяти все еще что-то висит, вот это уже гораздо серьезней. new и delete - это частность, но опять же вполне достойная внимания, особенно когда идет выделение памяти в циклах с миллионами итераций и более, а такое часто встречается в серьезных приложениях. Возможно я ошибаюсь, но утечка в 1 байт в таком цикле за 1-2 минуты запросто повесит как минимум приложение даже на самом мощном компьютере.
RE: как бы это опять же грамотно сказать то, в самом простом примере есть некое пространство
{
int i=0;
...
}
и в нем мы объявили i, если последить за переменной i в пошаговом режиме, то когда мы выйдем за пределы пространства - i станет не определено, (для MyList тоже самое), а вопрос в том, что подразумевает ли то что данная переменная уже не определена то что она была уже уничтожена. Почитаю лучше БС на эту тему, хотя там наверное все просто а-ля: компилятор компилятором, сделал переменную - убей переменную, но это же занудство на самом деле, просто нужно разобраться какие способы выделения памяти красиво обрабатываются компилятором, а какие нет. Кроме new и delete есть еще операторы выделения и очистки памяти(причем кажись они все парные), и если хотя бы одна такая пара обрабатывается некорректно, т.е. память выделили, а очистить забыли, приложение закрылось, а в памяти все еще что-то висит, вот это уже гораздо серьезней. new и delete - это частность, но опять же вполне достойная внимания, особенно когда идет выделение памяти в циклах с миллионами итераций и более, а такое часто встречается в серьезных приложениях. Возможно я ошибаюсь, но утечка в 1 байт в таком цикле за 1-2 минуты запросто повесит как минимум приложение даже на самом мощном компьютере.
Понимаешь, когда ты выделяешь переменную в стэке, например:
int i = 0;
То действительно, при выходе из области видимости память действительно освободится.
А вот если ты выделяешь память в куче, например с помощью new, то при выходе из области видимости, ты всеголишь теряешь указатель на этот блок памяти, а вот сам блок остается. То есть провоцируешь утечку памяти. Более подробно объяснит Green=))).
int i = 0;
То действительно, при выходе из области видимости память действительно освободится.
А вот если ты выделяешь память в куче, например с помощью new, то при выходе из области видимости, ты всеголишь теряешь указатель на этот блок памяти, а вот сам блок остается. То есть провоцируешь утечку памяти. Более подробно объяснит Green=))).