На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (56) « Первая ... 44 45 [46] 47 48 ...  55 56  ( Перейти к последнему сообщению )  
> D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?
    Цитата Qraizer @
    Так что вполне можно представить себе реализацию компилятора, который на каждый поинтер заводит счётчик, аддрефит и декрефит его при копировании, присваивании итп и следит за областями видимости этих поинтеров. Это сделает их практически неотличимыми от shared_ptr<>. В итоге получим в общем-то тот самый GC, который хороший, детерминированный и незаметный.

    Ну тот же swift примерно так и работает: https://developer.apple.com/library/content...ceCounting.html

    Но и там есть явные "слабые ссылки".

    И без них (или какого-то детектора циклов) ты никак не обойдешься.

    Добавлено
    Цитата negram @
    А RC - это сокращение для чего?

    Reference Counting
      Цитата D_KEY @
      Так я про это отличие и говорю :)
      Оно весьма важно.
      Оно важно, но не оно превращает GC в не-GC.
      Цитата D_KEY @
      Когда будет освобожден ресурс?
      Когда приспичит GC.
      Цитата D_KEY @
      Тут же мы говорим о сочетании в одном языке, в одной системе.
      Да. И вся аргументация сводится к "мне так кажется". Объективных причин как за смешивание так и против, я не вижу. И в D это не мешает. Мешает просто плохой GC.
      Цитата D_KEY @
      Без детектора циклов это не имеет смысл. А если он есть, то это уже не совсем RC. Это реализация сборщика через RC ;)
      В эрланге нет никаких детекторов цикла. Там RC применяется к объектам, которые принципиально не могут содержать ссылки на другие объекты. Для остальных generational GC.
      Цитата D_KEY @
      Сам же RC сборкой мусора не является. Вернее, в современных системах лучше эти понятия разделять.
      С чего ты взял?
        Цитата applegame @
        Оно важно, но не оно превращает GC в не-GC.

        Это является следствием работы того, что сейчас называют GC. Полноценная сборка мусора не в состоянии обеспечить детерминированное удаление.

        Цитата
        Объективных причин как за смешивание так и против, я не вижу


        В таком случае лучше не смешивать, ибо так проще. Зачем усложнять, если ценность не ясна?

        Добавлено
        Цитата applegame @
        Там RC применяется к объектам, которые принципиально не могут содержать ссылки на другие объекты

        Тогда это можно рассматривать в качестве оптимизации GC для конкретных случаев. От программиста что-то требуется?

        Цитата
        Цитата D_KEY @
        Сам же RC сборкой мусора не является. Вернее, в современных системах лучше эти понятия разделять.
        С чего ты взял?

        Это же просто классификация. Называя RC сборкой мусора легко ввести в заблуждение.

        Добавлено
        applegame, посмотри на статью про ARC в swift, что я выше привел. Как думаешь, удобно бы было, если бы они называли это сборкой мусора?
          Цитата Qraizer @
          Не согласен. Даже сырые поинтеры вполне можно контролировать "под капотом" технологией, похожей на C++EH. Напомню, что реализация C++EH никак не затрагивает классы и полностью обходится внешними по отношению к охраняемым им объектам структурами данных. Так что вполне можно представить себе реализацию компилятора, который на каждый поинтер заводит счётчик, аддрефит и декрефит его при копировании, присваивании итп и следит за областями видимости этих поинтеров. Это сделает их практически неотличимыми от shared_ptr<>. В итоге получим в общем-то тот самый GC, который хороший, детерминированный и незаметный.
          Только цена подобного решения будет велика. Если C++EH практически не сказывается на производительности кода, кроме собственно случаев, когда исключения выбрасываются, то такие поинтеры будут отнимать ресурсы ЦП постоянно. Т.к. принцип нулевой стоимости запрещает сие, поэтому и есть отдельные библиотечные типы, используя которые программер сознательно идёт на этот оверхед.
          Неполноценный GC получится, чреват утечками из-за циклических ссылок.
          Кроме того, почему-то считается, что такой GC будет медленнее современных incremental/generational GC.
            Цитата applegame @
            Неполноценный GC получится, чреват утечками из-за циклических ссылок.
            Почему это? Циклы аутоматично могут детектиться, кто мешает реализовать?
              Цитата Qraizer @
              Циклы аутоматично могут детектиться, кто мешает реализовать?

              Полноценно их можно детектить только в рантайме.
              И что ты с ними будешь делать автоматически?
                Цитата D_KEY @
                В таком случае лучше не смешивать, ибо так проще. Зачем усложнять, если ценность не ясна?
                А что усложняется? Ты можешь полностью забить на RAII и писать так же как пишешь на шарпе или жабе. А ценность ясна - ты можешь применять D для низкоуровневого кода. Я например на D даже микроконтроллеры прогаю, не пользуясь GC.
                Цитата D_KEY @
                Тогда это можно рассматривать в качестве оптимизации GC для конкретных случаев. От программиста что-то требуется?
                Как и в любом языке есть рекомендации в каких ситуациях как лучше поступать или наоборот не поступать.
                Цитата D_KEY @
                Это же просто классификация. Называя RC сборкой мусора легко ввести в заблуждение.
                То есть это вопрос чисто терминологии. Так как мы оба прекрасно понимаем, о чем говорим, то не вижу смысла в дальнейшем споре.
                Цитата D_KEY @
                applegame, посмотри на статью про ARC в swift, что я выше привел. Как думаешь, удобно бы было, если бы они называли это сборкой мусора?
                Да все равно, если честно. Написали бы, сборка мусора обеспечивается при помощи ARC, ничего бы не поменялось.
                  Цитата applegame @
                  Кроме того, почему-то считается, что такой GC будет медленнее современных incremental/generational GC.

                  Ну тут комплекс факторов. Ты не сможешь на такой основе сделать быстрое выделение памяти(которое в случае полноценного GC может сводится почти что к инкременту указателя), ибо нет фазы сборки, нет фазы перемещения и уплотнения объектов. Так же у тебя появляется оверхед на каждое копирование ссылки.
                  Да и замеры какие-то вроде проводили, но тут у меня есть сомнения в корректности.
                    Цитата Qraizer @
                    Почему это? Циклы аутоматично могут детектиться, кто мешает реализовать?
                    Реализовывали уже, в питоне и в Nim. Тормозно получается. Этож надо строить графы ссылок и искать в нем циклы. Поэтому этот детектор ссылок делают отключаемым.
                      Цитата applegame @
                      Да все равно, если честно. Написали бы, сборка мусора обеспечивается при помощи ARC, ничего бы не поменялось.

                      Хм. Ну а как бы ты описывал необходимость в слабых ссылках? Ведь они в языках с нормальным GC есть, только совсем другие и для других целей используются.

                      Добавлено
                      Цитата applegame @
                      А что усложняется? Ты можешь полностью забить на RAII и писать так же как пишешь на шарпе или жабе.

                      Тогда зачем мне D? Есть же kotlin и scala :D

                      Добавлено
                      Цитата applegame @
                      А ценность ясна - ты можешь применять D для низкоуровневого кода. Я например на D даже микроконтроллеры прогаю, не пользуясь GC.

                      Но ведь ты сам выше писал, что D gc-ориентированный. Неужели удобнее получается, чем на крестах или rust?
                        Цитата D_KEY @
                        Ну тут комплекс факторов. Ты не сможешь на такой основе сделать быстрое выделение памяти(которое в случае полноценного GC может сводится почти что к инкременту указателя), ибо нет фазы сборки, нет фазы перемещения и уплотнения объектов. Так же у тебя появляется оверхед на каждое копирование ссылки.
                        Да и замеры какие-то вроде проводили, но тут у меня есть сомнения в корректности.
                        Да, я в курсе аргументации противников ARC.
                        Несколько лет назад кто-то в D в свое время перехерачил весь рантайм на ARC и доложил о нехилом приросте скорости в какой-то там игре. Но это тоже не совсем корректный замер, так как дешный GC тормозной, и у него кто угодно выиграет.
                        Если бы все эти александрески не парили бы мозг и просто сделали бы те же плюсы, но с синтаксисом и шаблонами D, то очень вероятно, что сейчвс бы Qraizer топил бы за такой D.
                          Цитата applegame @
                          Реализовывали уже, в питоне и в Nim. Тормозно получается. Этож надо строить графы ссылок и искать в нем циклы.
                          Ну так как напрограмили, так и работает. Оптимизацию никто не запрещал.
                            Цитата D_KEY @
                            Хм. Ну а как бы ты описывал необходимость в слабых ссылках? Ведь они в языках с нормальным GC есть, только совсем другие и для других целей используются.
                            Да также бы и описывал. Мне неинтересно спорить на тему является ли ARC частным случаем GC или нет. В любом разговоре достаточно договориться о терминах, а там хоть горшком назови. Я твою точку зрения понял, и когда ты будешь писать GC я учту, что ты имеешь в виду "обычный" GC как в D, жабе и т. д.
                            Цитата D_KEY @
                            Тогда зачем мне D? Есть же kotlin и scala :D
                            Это риторический вопрос. Зачем kotlin и scala, когда есть D, Elixir и Haskell?
                            Цитата D_KEY @
                            Но ведь ты сам выше писал, что D gc-ориентированный. Неужели удобнее получается, чем на крестах или rust?
                            Да, удобнее, как ни странно. Фактически ты как бы пишешь на эдаких сильно прокачанных плюсах. Разве что библиотек нет вообще, поэтому чисто как хобби. Профессионально кодить МК на D - это безумие.
                            Цитата Qraizer @
                            Ну так как напрограмили, так и работает. Оптимизацию никто не запрещал.
                            Можно конечно предположить, что программисты в Apple криворукие, но я таки склонен полагать, что это не так просто как ты считаешь.
                            Сообщение отредактировано: applegame -
                              Цитата Qraizer @
                              Оптимизацию никто не запрещал.

                              Расскажешь, как бы ты сделал детектор циклов?

                              Добавлено
                              Цитата applegame @
                              Зачем kotlin и scala, когда есть D, Elixir и Haskell?

                              Проще же(хотя про scala это вряд ли можно сказать).
                              По крайней мере в рассматриваемом вопросе управления памятью.

                              Добавлено
                              В остальном согласен, там действительно больше о терминологии речь.
                                Цитата D_KEY @
                                Проще же(хотя про scala это вряд ли можно сказать).
                                По крайней мере в рассматриваемом вопросе управления памятью.
                                Не думаю, что проще. На D также легко писать как и на kotlin. Практически все дешные WAT-ы никак с GC не связаны.
                                Проблемы возникают, если в программе очень много GC-объектов болтающихся в памяти. У меня например в проекте их сотни тысяч. GC тормозит безбожно. Авторы D2 почему-то забили на опыт Apple. Насколько я помню, в Objective C долго пытались сделять полноценный GC. Мучались, пробовали и так и эдак, но в итоге забили и сделали ARC, потому, что в подобных языках полноценные GC получаются убогими.
                                Сообщение отредактировано: applegame -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (56) « Первая ... 44 45 [46] 47 48 ...  55 56


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0858 ]   [ 16 queries used ]   [ Generated: 29.03.24, 15:47 GMT ]