Шахты online

Как в Builder проверить течет память или нет

Суть в следующем в первом модуле есть глобальная переменная char *t.

Во втором модуле я ее определяю Form1->t = new char[str.Length()];

Потом при закрытии модуля (фрмы) 1 я удаляю эту глобальную переменную delete t;

Будет ли у меня течь память и как этот избежать в данной ситуации?

Пардо немного не так
во втором модуле

char *t = new char[str.Length()+1];
// а уже потом тут же но чуть позже
Form1->t = t;

Borr,

Как в Builder проверить течет память или нет

в Делфи2006 версии совершенно новый менеджер памяти, в котором можно включить проверку на утечки памяти RegisterMemoryLeak или что то в этом роде, насчет билдера - не в курсе.

ак же советую утилиту MemProf.

Во втором модуле я ее определяю Form1->t = new char[str.Length()];

Потом при закрытии модуля (фрмы) 1 я удаляю эту глобальную переменную delete t;

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

MemProf? а ссылочку

http://www.google.ru/search?hl=ru&q=Mem ... %D0%BA&lr=
первая ссылка

Спасибо MemProof не MemProf

Borr,
а.. точно )

утечки небудет)

Так играться с указателями плохо. В С++ рекомендуют (это я в уважаемой литературе нашел + уважаемые люди подсказали) где выделил память с помощью new там же делай и delete. А для таких случаев как этот лутше создавать классы.

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

Borr писал(а): помощью new там же делай и delete. А для таких случаев как этот лутше создавать классы.

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

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

tAZAR,

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

... и система с радостью сама прибъет все неосвобожденные прогой ресурсы

Eraser,
+1

... и система с радостью сама прибъет все неосвобожденные прогой ресурсы Very Happy

Это не наш метод! С классами намного проще вышло - не нужно передавать неизвестно куда указатели.

а если MDI приложение и new делаеш не для текущей формы а для главной (кнопочка на ToolBar'e или Tab на TabControl, для управления текущей формой) и вот тут аксес виолятион и задерет (текущая формочка то закрывается, а главная остается).

во-первых:
new blabla <-> delete blabla;
new blabla[size] <-> delete [] blabla;
Во-вторых, когда я вижу явный delete мне хочется обрубить программисту пальцы. Есть контейнер std::vector<T> - удовлетворяет 99% потребностей в массивах. Именно здесь его и нужно использовать.

std::vector<char> t;
//где-то в коде:
t.resize(str.length());
// Form1->t это char *
Form1->t = &t[0];
вектор сам освободит память когда надо.

Eraser писал(а):... и система с радостью сама прибъет все неосвобожденные прогой ресурсы

гм. а что, у нас в BC++ Garbage Collector появился ? Это каким, простите, хр...
Eraser, уж извини - но это тебе не Delphi и не VB. Это - C++. Выделил память - будь добр, удали. Иначе - leak цто пудов. гм. -1, батенька.