На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (245) « Первая ... 176 177 [178] 179 180 ...  244 245  ( Перейти к последнему сообщению )  
> Есть ли будущее у DELPHI?
    korvin, в утечке памяти самым главным является, ВНЕЗАПНО, утечка памяти, а не то, есть у тебя на нее ссылки или нет.
      Цитата korvin @
      И где тут потеря ссылок если ты их явно сохраняешь и очищаешь?

      потеря ссылок внутри for, ты же привел код:
      Цитата korvin @
      Попробуй удалить ссылки
      ExpandedWrap disabled
            for(int i = 0; i < 100; ++i)
            {
               int* p = new int[100];
               SomeFunc(p);
            }
            
            // здесь.


      Я попробовал и удалил. Точно так же как ты забыл отписаться от события и прикрываешься тем, что тебе эта память может понадобица, но в случае чего ты ее можешь удалить. Ну так я тоже удалил. Я просто глобально перегрузил оператор new[], который вызывается в данном случае для выделения памяти в цикле.
        Цитата D_KEY @
        Почему же? Если у меня свой менеджер памяти(если что, он вообще-то и так "мой" - стандартный реализован в виде библиотеки), я могу сделать ровно то же самое.


        Выходит, в с++ тоже не бывает утечек, бывает bad design, а вот good design-ом будет пройтись по структурам менеджера и грохнуть объект оттуда :D

        Добавлено
        Еще раз: утечка памяти - это не когда чисто теоретически осталась где-то валяться ссылка или не осталась, от того что она мертвым грузом где-то лежит никому не легче, утечка - это когда в коде не предусмотрено корректное освобождение памяти, которая больше никому никогда не понадобится, независимо от того, чисто теоретически возможно было бы это сделать или нет. Это не сделано чисто практически ;)

        Добавлено
        Цитата D_KEY @
        Ну, я тебя понял. В принципе, это спор исключительно о терминах.


        Нет, спор исключительно о сути ;) Иначе Корвину придется признать что в случаях с менеджером памяти тоже нет никаких утечек
        Сообщение отредактировано: --Ins-- -
          Цитата --Ins-- @
          Иначе Корвину придется признать что в случаях с менеджером памяти тоже нет никаких утечек

          Он видимо просто подходит к выделению памяти как к некоторому черному ящику, реализованному в языке, т.е. никакие менеджеры памяти не рассматривает в принципе.
            --Ins--, формально - GC "всего лишь" убирает утечки. Когда у программера есть GC, он становится ленивым. Вот и всё. Когда есть GC, утечек нет и быть не может, утечки могут быть только, когда нет GC. Я всё понял, у меня наступил ДЗЕН. Осталось только прикрутить GC к файлам, сокетам, окнам, семафорам... ну итд. Чё ж мы так ограничено ленимся, одной только памятью.
            korvin, ресурс утёк - значит он утёк. Благодарю, я теперь точно знаю, за что именно я ненавижу GCs, а то всё понять не мог. Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков.
              Цитата KILLER @
              потеря ссылок внутри for, ты же привел код:

              Какая ж это потеря, если ты их явно сохранил в g_List? =) Речь не о потере в каком-то конкретном месте, а потере во всей программе, так что ты программно сам не можешь до них достучаться.
                Цитата Qraizer @
                Когда есть GC, утечек нет и быть не может


                Может, все зависит от того, что GC считает утечкой, а что - нет ;) Чтобы точно сказать утечка или нет - нужен анализ кода
                Сообщение отредактировано: --Ins-- -
                  Цитата Qraizer @
                  Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков.

                  :lool: :good:
                    Цитата Qraizer @
                    Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков.

                    А я-то думал ты воспользуешься дополнительным свободным временем для чего-то полезного. =) Ты дом-то тоже сам строить будешь? И продукты питания выращивать? И электричество вырабатывать? =)
                      Цитата korvin @
                      Какая ж это потеря, если ты их явно сохранил в g_List? =)

                      Ну а так их сохранил менеджер памяти :) И он точно так же не является частью языка.
                        Цитата Qraizer @
                        Осталось только прикрутить GC к файлам, сокетам, окнам, семафорам... ну итд. Чё ж мы так ограничено ленимся, одной только памятью.

                        Почему бы и нет? В случаях, когда нам не нужно гарантированное закрытие файла в определенный момент, вполне можно это дать на откуп менеджеру какому-нибудь.
                          Цитата [S]mike @
                          Тот же Эклипс может потреблять всего 500 метров максимум.
                          omg!!


                          Прикреплённая картинка
                          Прикреплённая картинка
                            Цитата Qraizer @
                            korvin, ресурс утёк - значит он утёк. Благодарю, я теперь точно знаю, за что именно я ненавижу GCs, а то всё понять не мог. Когда за мной начнёт убираться домработница, я уйду в дом пожилых престарелых маразматиков.


                            Угу, что-то в этом есть... Опасность таких утечек, когда для GC формально утечки нет, но по факту - результат такой же, еще и в том, что это будет большим сюрпризом для программиста, который на GC рассчитывал и об утечках даже и не задумывался. А ведь философия GC ведь этому и учит - не задумываться и вырученное время потратить на (нужное вписать)
                              Цитата D_KEY @
                              Ну а так их сохранил менеджер памяти :) И он точно так же не является частью языка.

                              Т.е. ты хочешь сказать, что все ссылки дублируются?

                              Добавлено
                              Цитата --Ins-- @
                              Угу, что-то в этом есть... Опасность таких утечек, когда для GC формально утечки нет, но по факту - результат такой же, еще и в том, что это будет большим сюрпризом для программиста, который на GC рассчитывал и об утечках даже и не задумывался. А ведь философия GC ведь этому и учит - не задумываться и вырученное время потратить на (нужное вписать)

                              Ты знаешь, программист никогда не подумал бы, что раз он добавил объект в список, то он оттуда самопроизвольно удалится.
                                Именно, --Ins--. Всё что утерял программер, т.е. все его утечки ресу... э-э-э, памяти, подчистит GC, и это уже не будет утечкой. Но вот то, что GC подчистить не сможет, будет утечкой, но не утечкой, потому что называться будет иначе, т.к. на такие утеч... тьфу ты, та что ж такое-то... ситуации GC не рассчитан, а значит они не могут считаться утечками. Другими словами, с утечками GC справится, а с неутечками придётся справляться нам. Как-нибудь. Например, грохая весь список подписчиков раз в сутки. Ну или весь хип, когда тот разрастётся до 15 Гб.
                                Я наверное дурак... но я всё-таки думаю, что лучше просто, чем сложно. Не? Зачем придумывать способы бороться с неутечками GC, если можно без утечек и без GC.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (245) « Первая ... 176 177 [178] 179 180 ...  244 245


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,2559 ]   [ 17 queries used ]   [ Generated: 21.12.25, 06:10 GMT ]