На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (56) « Первая ... 53 54 [55] 56   ( Перейти к последнему сообщению )  
> D vs C++, почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?
    Цитата D_KEY @
    Вот мне помнится, что по крайней мере в скорости вызовов не просирает, а чуть ли не выигрывает
    Скорость вызова одинакова, я зырил асм.
    Цитата D_KEY @
    Нахрена?
    Затем же зачем и
    ExpandedWrap disabled
      pragma(inline, false)

    Иначе и clang и ldc оптимизируют bar в нуль: вернуть 20. :lol:

    Добавлено
    Сравниваем шаблонные версии:
    D:
    ExpandedWrap disabled
      pragma(inline, false)
      void foo(alias fn)() {
          fn(10);
      }
       
      int bar() {
          int i = 10;
          foo!((int x){
              i += x;
          });
          return i;
      }


    ExpandedWrap disabled
      template<typename F>
      __attribute((noinline))
      void foo(F fn) {
          fn(10);
      }
       
      int bar() {
          int i = 10;
          foo([&i](int x){
              i += x;
          });
          return i;
      }
    error: 'long long long' is too long for GCC
      Смотрим асм.
      D:
      ExpandedWrap disabled
        int example.bar():
                push    rax
                mov     dword ptr [rsp], 10
                mov     rdi, rsp
                call    pure nothrow @nogc @safe void example.foo!(example.bar().__lambda1(int)).foo()@PLT
                mov     eax, dword ptr [rsp]
                pop     rcx
                ret
         
        pure nothrow @nogc @safe void example.foo!(example.bar().__lambda1(int)).foo():
                add     dword ptr [rdi], 10
                ret


      С++:
      ExpandedWrap disabled
        bar():                                # @bar()
                push    rax
                mov     dword ptr [rsp + 4], 10
                lea     rdi, [rsp + 4]
                call    void foo<bar()::$_0>(bar()::$_0)
                mov     eax, dword ptr [rsp + 4]
                pop     rcx
                ret
         
        void foo<bar()::$_0>(bar()::$_0):                 # @"void foo<bar()::$_0>(bar()::$_0)"
                add     dword ptr [rdi], 10
                ret


      В данном случае дешный асм либо равен либо лучше плюсового. Так то.

      Добавлено
      Но это все ситуативные оптимизации. Полагаю, что производительность C++ и D можно считать одинаковой, при прочих равных.
      error: 'long long long' is too long for GCC
        Цитата applegame @
        void foo(std::function<void(int)> fn) {
        Нахрена?

        Добавлено
        А, сорри, страничка новая.
        Одни с годами умнеют, другие становятся старше.
          Цитата applegame @
          А вот можно ли в плюсах создать "типизированную" лямбду (std::function<void(int)> например) с замыканиями, но без аллокаций в куче?
          Цитата D_KEY @
          Ну если тебя не устроит auto f = ... или передача в шаблон функции, то нет.
          Насколько я понимаю, нет синтаксиса, чтобы типизировать лямбду явно. А неявно компилятор в любом случае её типизирует (поскольку с нетипизированными объектами работать не умеет)
          И, насколько понимаю, для замыкания всегда выделяется память в стеке.
          Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
            Цитата amk @
            И, насколько понимаю, для замыкания всегда выделяется память в стеке.
            Для замыканий память по любому нужна. Хоть какая-нибудь где-то там. Вопрос "можно ли без аллокаций", думаю, надо понимать как "можно ли без dynamic storage".

            Добавлено
            Вопрос в другом: почему хочется без dynamic storage? ИМХО только лишь из-за проблем с производительностью и отсутствием явных языковых правил для dynamic storage duration. С GC можно было бы не париться за duration, но вопрос производительности только ужесточился бы. std::function<> должен быть готов работать с любым объектом, чей интерфейс имеет реализацию указанного operator(), а значит не может не быть полиморфным, а значит в объектной модели C++ должен работать с объектами косвенно, а значит посредством dynamic storage и указателями. Причём с подсчётом ссылок, ибо иначе std::function<> не имел бы семантику значений.
            Одни с годами умнеют, другие становятся старше.
              Цитата Qraizer @
              std::function<> должен быть готов работать с любым объектом, чей интерфейс имеет реализацию указанного operator()

              Делегаты в D обладают подобным же свойством.
              "If someone claims to have the perfect programming language, he is either a fool or a salesman or both"(c) Bjarne Stroustrup
                Но я-то за Плюсы. Динамический полиморфизм за интерфейсом скрывает информацию об исходном типе, однако её сохраняет статический полиморфизм. Так что да, где спасовал std::function<>, вывозит шаблон.
                Одни с годами умнеют, другие становятся старше.
                  Цитата Qraizer @
                  Для замыканий память по любому нужна. Хоть какая-нибудь где-то там.
                  Какая-нибудь нужна, но в D нередко можно обойтись без дополнительной памяти для замыканий. Ни стековой ни dynamic storage ни GC. Плюсы́ такого фокуса, ЕМНИП, не умеют.
                  Цитата Qraizer @
                  Но я-то за Плюсы. Динамический полиморфизм за интерфейсом скрывает информацию об исходном типе, однако её сохраняет статический полиморфизм. Так что да, где спасовал std::function<>, вывозит шаблон.
                  Ну этот подход работает и в D, так что здесь преимуществ нет.
                  Сообщение отредактировано: applegame -
                  error: 'long long long' is too long for GCC
                    Цитата applegame @
                    Ни стековой ни dynamic storage ни GC.
                    Каким образом?
                    Цитата applegame @
                    Ну этот подход работает и в D, так что здесь преимуществ нет.
                    Причём тут преимущества? Я за недостатки. Просто иначе std::function<> не может быть устроен. Другое дело шаблон, он недостатка не имеет.
                    Одни с годами умнеют, другие становятся старше.
                      Цитата Qraizer @
                      Каким образом?
                      Если время жизни лямбды меньше времени жизни переменных замыкания, то можно не резервировать дополнительную память, а обращаться напрямую к данным на стеке. D так умеет. Я приводил пример:
                      ExpandedWrap disabled
                        void foo(scope void delegate(int) fn) {
                            fn(10);
                        }
                         
                        int bar() {
                            int i = 10;
                            foo((int x){
                                i += x;
                            });
                            return i;
                        }

                      В данном случае в foo передается делегат, время жизни которого, меньше, чем переменной замыкания i. Компилятор знает, что делегат никуда не утечет из функции foo, благодаря атрибуту scope. В foo будет передан указатель на функцию делегата и указатель на стековый фрейм с переменной i.
                      Цитата Qraizer @
                      Причём тут преимущества? Я за недостатки. Просто иначе std::function<> не может быть устроен.
                      А, окай, я тебя неверно понял.
                      Цитата Qraizer @
                      Другое дело шаблон, он недостатка не имеет.
                      Но есть другой недостаток: например, нельзя сделать массив лямбд с одинаковой сигнатурой, но разными замыканиями.
                      Сообщение отредактировано: applegame -
                      error: 'long long long' is too long for GCC
                        А какие преимущества перед шаблоном в данном случае?

                        Добавлено
                        Цитата applegame @
                        Но есть другой недостаток: например, нельзя сделать массив лямбд с одинаковой сигнатурой, но разными замыканиями.

                        А для такого случая эта штука со scope как будет работать?
                        "If someone claims to have the perfect programming language, he is either a fool or a salesman or both"(c) Bjarne Stroustrup
                          Цитата applegame @
                          Если время жизни лямбды меньше времени жизни переменных замыкания, то можно не резервировать дополнительную память, а обращаться напрямую к данным на стеке. D так умеет
                          Так это просто оптимизация. Оптимизировать и C++ умеет. Для общего-то случая такая оптимизация не гарантируется.
                          Одни с годами умнеют, другие становятся старше.
                            Цитата D_KEY @
                            А какие преимущества перед шаблоном в данном случае?
                            Даже с шаблоном под замыкания в плюсовой лямбде будет выделена память как минимум на стеке. Например, на стеке лежит переменная, а в замыкании ссылка на эту переменную. Ну и template code bloat никто не отменял.
                            Цитата D_KEY @
                            А для такого случая эта штука со scope как будет работать?
                            К такой штуке scope не прикрутишь никак. Тут будут аллокации в GC. Либо можно как в плюсах хранить функторы аналогичные std::function.
                            Цитата Qraizer @
                            Так это просто оптимизация. Оптимизировать и C++ умеет. Для общего-то случая такая оптимизация не гарантируется.
                            Плюсы не смогут сделать такую оптимизацию в общем случае. В плюсах нет scope.

                            Но в целом это мелочь, я считаю. Но интересная, на мой взгляд.
                            Сообщение отредактировано: applegame -
                            error: 'long long long' is too long for GCC
                              Цитата applegame @
                              Плюсы не смогут сделать такую оптимизацию в общем случае. В плюсах нет scope.
                              Во-первых, это сделано в твоём собственном листинге вверху. Я даже проверил, визуалка тоже так умеет. Во-вторых, в Плюсах нет и Cёвого restrict. По той же причине, подозреваю, почему нет scope.
                              Одни с годами умнеют, другие становятся старше.
                                Цитата D_KEY @
                                Потому, что будет легче на него перейти и переводить существующие системы на него.

                                Ну вон в Go нет «нормального ООП» и вообще никакого параметрического полиморфизма, да и обработка ошибок не «нормальная» (привычна разве что для махровых Сишников). Каналы, опять же, для многих «программистов на мейнстримных языках» — не сильно привычный способ синхронизации. Но достаточно много людей его таки начали использовать.
                                “Object-oriented design is the roman numerals of computing.” — Rob Pike
                                All software sucks
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (56) « Первая ... 53 54 [55] 56 


                                Рейтинг@Mail.ru
                                [ Script Execution time: 0,2327 ]   [ 17 queries used ]   [ Generated: 18.10.19, 04:09 GMT ]