1. PHP / Говнокод #17070

    +161

    1. 1
    2. 2
    3. 3
    4. 4
    /**
        * Деструктор
        */
        public function __destruct(){

    Публичная функция деструктор - пиши подробнее!

    Запостил: Elfet, 05 Ноября 2014

    Комментарии (29) RSS

    • вот просто интересно: а что пыхопешники делают в деструкторах?
      Ответить
      • Деструкторы скорее всего нужны для авторов библиотек, которые работают с Си кодом, например. Хотя вполне можно было бы там, например, закрывать подключение к базе данных. Но это я только предполагаю. Хз. как там ПХП рантайм себя ведет в нештатных ситуациях с деструкторами и т.п.
        Ответить
        • мне вот не кажется что там нужно закрывать подключение к базе данных, потому что в языках без явного управляения памятью деструкторы вызываются не очень детерминированно)

          вариант про си -- ок, хотя и это диковато
          Ответить
          • В пыхе практически явное управление памятью на счетчиках ссылок (если не мутить циклические структуры, ради которых через некоторое время запустится gc). Так что деструкторы должны неплохо отрабатывать.
            Ответить
            • >> если не мутить циклические структуры

              именно о них я и говорил.

              когда придет гц совершенно непонятно.

              использовать ~ в качестве подстраховки можно, но завязываться на него -- нет.
              ------

              и фообще

              By default, PHP's garbage collector is turned on. There is, however, a php.ini setting that allows you to change this: zend.enable_gc.

              ха-ха-ха
              Ответить
              • Ну так в питоне примерно то же самое. Только конфига нет, но сборщик можно программно отключить.
                С другой стороны, в питоне есть конструкция with для предсказуемого управления ресурсами.
                Ответить
                • да-да, и она дергает __exit__, если мне не изменяет склероз

                  всё лучше
                  Ответить
                  • Ну в общем-то та же идея, что и в try with resources в жабе и using (или как там его) в шарпе.
                    Ответить
                    • Да, именно они.

                      Причем заметьте: финалайзер в джаве и финалайзер в .NET (в случае c# он еще алиас деструктора) в этом шабаше не участвует.
                      Ответить
                      • Да финалайзеры в джаве и шарпе, имхо, почти бесполезны. Любой ресурс кроме памяти всё равно придется освобождать через finally, using'и или вручную.

                        P.S. Вот за это я немного недолюбливаю языки с gc - обещали автоматическое управление памятью, а на деле - все файлы и т.п. руками закрывать. И RAII, как в крестах, уже не запилишь.
                        Ответить
                        • Да в общем они всегда бесполезны. Хуже того: есть шанс что они вообще никогда не выполнятся.
                          Ответить
                          • Сколько же полезного можно узнать на govnokod'e :)
                            Ответить
                            • Еще больше можно узнать в JLS: http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6
                              Ответить
                        • >с gc - обещали автоматическое управление памятью
                          Памятью, а не ресурсами (в т.ч. удалёнными).
                          В целом конечно согласен. С сахарком в виде try with resources/using вроде стало поудобнее, но чтоб автоматически почистило по выходу из скоупа — до этого еще расти и расти.

                          Плюс крестоподход может автоматически освобождать лочки (что в принципе опять-таки ресурс).
                          А в жабе/шарпе сахарок syncronized(Obj) / lock(Obj) плюс старое-доброе
                          lock.aquire(); //тут try-with-resources не сделали
                          try{
                          }finally{
                             lock.release();
                          }
                          Разве что через лямбды (что само по себе оверхед), как делают в linq.
                          Ответить
                        • Финалайзеры нужны для всяких хитрых кешей и прочей тонкой магии.
                          Вот сколько работаю, никогда ничего такого мудрённого типа фантомных/мягких ссылок не писал.

                          Кстати постоянный и любимый вопрос ревьюверов на всяких собеседованиях. Спрашивается толку-то?
                          Мне кажется у таких ревьюверов не хватает практики, чтоб понять что знание таких вещей особо не помогает и/или фантазии чтоб придумать действительно кошерные вопросы.

                          Лучше б про stop-the-world спрашивали и тюнинг VM. Это действительно проблема, и надо уметь её сглаживать.
                          А то у многих такое ощущение будто GC — silver bullet.
                          Ответить
                          • > stop-the-world
                            Остановите землю, я сойду. Вроде бы на -server включается более вменяемый сборщик?

                            Кстати, а что интересного и полезного можно натюнить помимо лимитов памяти да включения хотспота?
                            Ответить
                            • > а что интересного и полезного можно натюнить
                              Ну максимальная задержка сборок (но чем меньше поставить, тем чаще они будут срабатывать), survior ratio, пропорцию выделения памяти между олдгеном и новыми поколениями.
                              Потом там всякие штуки типа выгрузки классов и permgenа (раньше было особенно актуально, ибо он постоянно засирался).
                              Еще есть compressed oops и compressed strings. Т.к. в жабе всё измеряется по 8 байт, то 32-битным указателем можно адресовать (4Г*8байт)=32 гига. В былые времена на 64-битных машинах из-за этого падал пирфоманс.
                              Вторая фича по возможно хранит однобайтовые ansi-строки. Меньше размеры объектов => меньше куча => быстрее собирается.

                              >Вроде бы на -server включается более вменяемый сборщик?
                              На -server включаются многие более агресивные оптимизации. Например начинают инлайниться виртуальные методы.
                              Ответить
                              • > На -server включаются многие более агресивные оптимизации.
                                Сейчас, ради фана и изучения NIO, набросал с использованием NIO и JCA считалку sha-256. Так она с -server всего в 1.5 раза медленней получилась, чем выдроченная сишная sha256sum...

                                P.S. Или в JCA криптопровайдеры нативные?
                                Ответить
                                • >Или в JCA криптопровайдеры нативные?
                                  Полагаю всё оно юзает жаба-реализации. Это ж не питон с сишными ушами.
                                  Там политика такая - поменьше нативного. Там всё, и gzip, и прочая математика реализованы средствами языка.
                                  Ответить
                                  • > Там политика такая - поменьше нативного.
                                    Ага, мне больше всего понравилось, что дрова для СУБД написаны на чистой жабе и не требуют никаких SDK, библиотек и прочего говна.

                                    > Полагаю всё оно юзает жаба-реализации
                                    Тогда это очень неплохой результат, имхо.
                                    Ответить
                                    • Есть и обратная сторона.

                                      Допустим у Вас есть либа libfoo.
                                      Соответственно есть утилита foo и файлик foo.conf в домашней папке, и все привыкли что если в нем прописать что надо, то всё работает.

                                      Так как пайтон, перл, пых итд всего-лишь обёртки вокруг этой либы, то если работает с консоли то работает и в них.

                                      А вот пришла жава и срать хотела на libfoo, и пользователь рвет на жопе волосы: почему у него всё сконфигурено, но ничего не работает.
                                      Ответить
                • Вот уж не знал, что в питоне есть сборщик мусора. Я-то думал, он объекты убивает сразу, как на них перестали ссылаться. Прям аж перехотелось закапываться в дебри этого языка.
                  Ответить
                  • Вроде бы такой же как в пыхе: только на аварийный случай, если всё засрали оторванными от рутов циклами.

                    http://effbot.org/pyfaq/how-does-python-manage-memory.htm

                    The standard C implementation of Python uses reference counting to detect inaccessible objects, and a separate mechanism to collect reference cycles, periodically executing a cycle detection algorithm which looks for inaccessible cycles and deletes the objects involved.
                    Ответить
                  • https://docs.python.org/2/library/gc.html

                    Понять когда на объект перестали ссылаться не всегда легко. Почитайте про Islands Of Isolation, например.

                    Потому чаще всего используют на выбор два подхода: или это предлагается делать программисту, или переодически считать транзитивные ссылки на все объекты в куче из стеков каждого живого потока (плюс еще место куда классы загружены).
                    Ответить
      • А ещё в деструкторе можно выплюнуть всё накопившееся за время работы в базу там, или в файл, или ещё куда-нибудь. Или отправить некий код завершения сеанса. Удобный метод. Терпишь, терпишь, а потом раз - и...
        Ответить
        • Не стоит это абузить... Роллбеки и закрытия - можно. А вот сохранять данные в деструкторе - не самая хорошая идея, по крайней мере в крестах.
          Ответить
          • Ах, если бы PHP были бы крестами...
            Ответить

    Добавить комментарий