Есть ли будущее у DELPHI?
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.43] |
|
|
Правила раздела:
| Страницы: (245) « Первая ... 176 177 [178] 179 180 ... 244 245 ( Перейти к последнему сообщению ) |
Есть ли будущее у DELPHI?
|
Сообщ.
#2656
,
|
|
|
|
korvin, в утечке памяти самым главным является, ВНЕЗАПНО, утечка памяти, а не то, есть у тебя на нее ссылки или нет.
|
|
Сообщ.
#2657
,
|
|
|
|
потеря ссылок внутри for, ты же привел код: Цитата korvin @ Попробуй удалить ссылки ![]() ![]() for(int i = 0; i < 100; ++i) { int* p = new int[100]; SomeFunc(p); } // здесь. Я попробовал и удалил. Точно так же как ты забыл отписаться от события и прикрываешься тем, что тебе эта память может понадобица, но в случае чего ты ее можешь удалить. Ну так я тоже удалил. Я просто глобально перегрузил оператор new[], который вызывается в данном случае для выделения памяти в цикле. |
|
Сообщ.
#2658
,
|
|
|
|
Цитата D_KEY @ Почему же? Если у меня свой менеджер памяти(если что, он вообще-то и так "мой" - стандартный реализован в виде библиотеки), я могу сделать ровно то же самое. Выходит, в с++ тоже не бывает утечек, бывает bad design, а вот good design-ом будет пройтись по структурам менеджера и грохнуть объект оттуда Добавлено Еще раз: утечка памяти - это не когда чисто теоретически осталась где-то валяться ссылка или не осталась, от того что она мертвым грузом где-то лежит никому не легче, утечка - это когда в коде не предусмотрено корректное освобождение памяти, которая больше никому никогда не понадобится, независимо от того, чисто теоретически возможно было бы это сделать или нет. Это не сделано чисто практически Добавлено Нет, спор исключительно о сути Иначе Корвину придется признать что в случаях с менеджером памяти тоже нет никаких утечек |
|
Сообщ.
#2659
,
|
|
|
|
Цитата --Ins-- @ Иначе Корвину придется признать что в случаях с менеджером памяти тоже нет никаких утечек Он видимо просто подходит к выделению памяти как к некоторому черному ящику, реализованному в языке, т.е. никакие менеджеры памяти не рассматривает в принципе. |
|
Сообщ.
#2660
,
|
|
|
|
--Ins--, формально - GC "всего лишь" убирает утечки. Когда у программера есть GC, он становится ленивым. Вот и всё. Когда есть GC, утечек нет и быть не может, утечки могут быть только, когда нет GC. Я всё понял, у меня наступил ДЗЕН. Осталось только прикрутить GC к файлам, сокетам, окнам, семафорам... ну итд. Чё ж мы так ограничено ленимся, одной только памятью.
korvin, ресурс утёк - значит он утёк. Благодарю, я теперь точно знаю, за что именно я ненавижу GCs, а то всё понять не мог. Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков. |
|
Сообщ.
#2661
,
|
|
|
|
Цитата KILLER @ потеря ссылок внутри for, ты же привел код: Какая ж это потеря, если ты их явно сохранил в g_List? =) Речь не о потере в каком-то конкретном месте, а потере во всей программе, так что ты программно сам не можешь до них достучаться. |
|
Сообщ.
#2662
,
|
|
|
|
Цитата Qraizer @ Когда есть GC, утечек нет и быть не может Может, все зависит от того, что GC считает утечкой, а что - нет Чтобы точно сказать утечка или нет - нужен анализ кода |
|
Сообщ.
#2663
,
|
|
|
|
Цитата Qraizer @ Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков. |
|
Сообщ.
#2664
,
|
|
|
|
Цитата Qraizer @ Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков. А я-то думал ты воспользуешься дополнительным свободным временем для чего-то полезного. =) Ты дом-то тоже сам строить будешь? И продукты питания выращивать? И электричество вырабатывать? =) |
|
Сообщ.
#2665
,
|
|
|
|
Цитата korvin @ Какая ж это потеря, если ты их явно сохранил в g_List? =) Ну а так их сохранил менеджер памяти И он точно так же не является частью языка. |
|
Сообщ.
#2666
,
|
|
|
|
Цитата Qraizer @ Осталось только прикрутить GC к файлам, сокетам, окнам, семафорам... ну итд. Чё ж мы так ограничено ленимся, одной только памятью. Почему бы и нет? В случаях, когда нам не нужно гарантированное закрытие файла в определенный момент, вполне можно это дать на откуп менеджеру какому-нибудь. |
|
Сообщ.
#2667
,
|
|
|
|
|
Сообщ.
#2668
,
|
|
|
|
Цитата Qraizer @ korvin, ресурс утёк - значит он утёк. Благодарю, я теперь точно знаю, за что именно я ненавижу GCs, а то всё понять не мог. Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков. Угу, что-то в этом есть... Опасность таких утечек, когда для GC формально утечки нет, но по факту - результат такой же, еще и в том, что это будет большим сюрпризом для программиста, который на GC рассчитывал и об утечках даже и не задумывался. А ведь философия GC ведь этому и учит - не задумываться и вырученное время потратить на (нужное вписать) |
|
Сообщ.
#2669
,
|
|
|
|
Цитата D_KEY @ Ну а так их сохранил менеджер памяти И он точно так же не является частью языка.Т.е. ты хочешь сказать, что все ссылки дублируются? Добавлено Цитата --Ins-- @ Угу, что-то в этом есть... Опасность таких утечек, когда для GC формально утечки нет, но по факту - результат такой же, еще и в том, что это будет большим сюрпризом для программиста, который на GC рассчитывал и об утечках даже и не задумывался. А ведь философия GC ведь этому и учит - не задумываться и вырученное время потратить на (нужное вписать) Ты знаешь, программист никогда не подумал бы, что раз он добавил объект в список, то он оттуда самопроизвольно удалится. |
|
Сообщ.
#2670
,
|
|
|
|
Именно, --Ins--. Всё что утерял программер, т.е. все его утечки
Я наверное дурак... но я всё-таки думаю, что лучше просто, чем сложно. Не? Зачем придумывать способы бороться с неутечками GC, если можно без утечек и без GC. |