Есть ли будущее у DELPHI?

Цитата KILLER @ 19.11.12, 12:58

То что там было приведено с тем же for:

for(int i = 0; i < 100; ++i)
{
   int* p = new int[100];
}

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

for(int i = 0; i < 100; ++i)
{
   int* p = new int[100];
 
   SomeFunc(p);
 
   delete [] p;
}

Так сказать неограниченно растущий кэш - не является мем. ликом.

Ты вообще не понимаешь о чем речь?

В первом варианте есть утечка, потому что ты теряешь ссылки. Во втором варианте ты их не теряешь.

Попробуй удалить ссылки

for(int i = 0; i < 100; ++i)
{
   int* p = new int[100];
   SomeFunc(p);
}
 
// здесь.

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

Например (псевдокод)

Form.Close()
Events.UnsubsribeAll(Events.SubscribersOf(Form))

В C++-примере выше после цикла ты уже ничего подобного не можешь сделать.

Добавлено 19.11.12, 13:23

Цитата KILLER @ 19.11.12, 13:17

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

Я не делал из этого ответ на вопрос.

Цитата KILLER @ 19.11.12, 13:17

Просто когда память закончится, что моя программа, что твоя - обе упадут по out of memory. И виной будет именно нерациональное использование памяти что в твоем, что в моем случае, утечка памяти попросту говоря. Так как ты не знаешь какую память тебе нужно освободить. И мне почему то кажется, что в твоем случае просто так, как ты говоришь не сделаешь, нужно еще найти эту ненужную ссылку.

Ну так "нерациональное использование памяти" != "утечка памяти".

Цитата korvin @ 19.11.12, 13:20

В первом варианте есть утечка, потому что ты теряешь ссылки. Во втором варианте ты их не теряешь.

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

Цитата korvin @ 19.11.12, 13:20

Попробуй удалить ссылки

    
for(int i = 0; i < 100; ++i)
    {
       int* p = new int[100];
       SomeFunc(p);
    }
 
    // здесь.

Это уже заплатка плять, как и в твоем случае с сылками. Я могу перегрузить оператор new/delete, и запоминать в отдельной переменной то что выделил, и возьму удалю там вот память, но код этот написанный тобой я трогать не буду. Это докажет тебе что это не утечка? А?

Цитата korvin @ 19.11.12, 13:20

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

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

Цитата korvin @ 19.11.12, 13:20

В C++-примере выше после цикла ты уже ничего подобного не можешь сделать.

Да конечно...

Цитата korvin @ 19.11.12, 13:10

Вообще-то я на него ответил, смотри внимательней тред.

Только я не понял ответ... Ты подписал объект на событие, потом потерял ссылку на объект - доступа к объекту у тебя нет, ты не можешь его отписать. Почему не утечка то?

Цитата korvin @ 19.11.12, 13:20

Ну так "нерациональное использование памяти" != "утечка памяти".

А что это? Ну значит я могу тоже заявить что в С++ под виндой во всяком случае есть GC, и можно не следить за памятью.

Цитата korvin @ 19.11.12, 13:20

В первом варианте есть утечка, потому что ты теряешь ссылки. Во втором варианте ты их не теряешь.

Здесь нет утечки?

void f()
{
    std::vector<int*> v;
    for(int i = 0; i < 100; ++i)
    {
       v.push_back(new int[100]);
    }
}

Цитата korvin @ 19.11.12, 13:20

В C++-примере выше после цикла ты уже ничего подобного не можешь сделать.

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

Цитата MyNameIsIgor @ 19.11.12, 13:28

Почему не утечка то?

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

Цитата MyNameIsIgor @ 19.11.12, 13:28

Только я не понял ответ... Ты подписал объект на событие, потом потерял ссылку на объект - доступа к объекту у тебя нет, ты не можешь его отписать. Почему не утечка то?

Потому что ссылка есть, она в списке подписчиков.

Цитата korvin @ 19.11.12, 13:20

В C++-примере выше после цикла ты уже ничего подобного не можешь сделать.

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

Добавлено 19.11.12, 13:34

Цитата korvin @ 19.11.12, 13:33

Потому что ссылка есть, она в списке подписчиков.

Так тебе же говорили уже, что менеджер памяти тоже хранит выделенные блоки.

Цитата KILLER @ 19.11.12, 13:26

Это уже заплатка плять, как и в твоем случае с сылками. Я могу перегрузить оператор new/delete, и запоминать в отдельной переменной то что выделил, и возьму удалю там вот память, но код этот написанный тобой я трогать не буду. Это докажет тебе что это не утечка? А?

Конечно, ты же удалил память и не потерял ссылки. =)

Цитата korvin @ 19.11.12, 13:35

Конечно, ты же удалил память и не потерял ссылки. =)

Ну так лови код, пойдет?

#include <stdlib.h>
#include <list>
 
std::list<int*> g_List;
 
void *operator new[](size_t size)
{
   g_List.push_back( (int*)malloc(size ) );
   return (void*)g_List.back();
}
 
int main()
{
   for(int i = 0; i < 100; ++i)
   {
      int* p = new int[100];
   }
 
   // здесь.
   for(std::list<int*>::iterator it = g_List.begin(); it != g_List.end(); ++it)
   {
      delete *it;
   }
 
   return 0;
}

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

Сообщение отредактировано: KILLER - 19.11.12, 13:41

korvin, ты знаешь, что в С вообще нет динамической памяти в самом языке, а malloc/free - это библиотечные функции?

Цитата D_KEY @ 19.11.12, 13:28

Здесь нет утечки?

void f()
{
    std::vector<int*> v;
    for(int i = 0; i < 100; ++i)
    {
       v.push_back(new int[100]);
    }
}

Я не знаю, как работает std::vector (удалит ли он память, выделенную под элементы при собственном удалении, думаю, что нет => да, утечка будет). В аналогичном коде с GC -- нет, т.к. при выходе из f исчезнет единственная ссылка на v и все его содержимое перестанет существовать.

Цитата korvin @ 19.11.12, 13:44

Я не знаю, как работает std::vector (удалит ли он память, выделенную под элементы при собственном удалении, думаю, что нет => да, утечка будет). В аналогичном коде с GC -- нет, т.к. при выходе из f исчезнет единственная ссылка на v и все его содержимое перестанет существовать.

А если вектор будет создан глобально? Не будет утечки?

Добавлено 19.11.12, 13:46
Ну, я тебя понял. В принципе, это спор исключительно о терминах.

Цитата KILLER @ 19.11.12, 13:40

Ну так лови код, пойдет?

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

И где тут потеря ссылок если ты их явно сохраняешь и очищаешь?