1. C++ / Говнокод #23679

    +1

    1. 1
    https://habrahabr.ru/post/347688/

    Ученые выяснили, что плюсы медленнее си.

    Запостил: g0cTb, 28 Января 2018

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

    • Тупые крестобляди каждый элемент очереди с приоритетами создают на куче отдельно. Ха-ха, кресты говно!

      template <class T> class priority_queue
      {
          struct node
          {   
              unsigned int m_weight;
              T m_data;
          };
      
          using node_ptr = std::unique_ptr<node>;
      
          std::size_t m_capacity;
          std::size_t m_size;
          std::unique_ptr<node_ptr[]> m_nodes;
      Ответить
      • автор статьи же не крестоблядь, а сишник с претензией на базовые знания плюсов.
        Ответить
      • Хуйчик-хуйчик.
        Ответить
      • а это реальная проблема. я слышал обсуждения перевода встроенных проектов на кресты, и это был тихий ужас.

        если хочешь пользоватся крестами - то классы это обязательно. и наследование вынуждают кресты тоже использовать. и еще надо операторов перегруженых вхуячить. самое главное - все объекты выделять динамически с new. потом сделать драму из исключений, потому что мы их не поддерживаем.

        "какой говняный язык, не будем им пользоватся." - почти буквальная цитата.
        Ответить
        • А ещё STL в прошивку не влезает, а буст раздувает код.
          Ответить
          • std::vector<bool> потребляет больше памяти, чем экономит из-за того, что раздувает прошивку!
            Ответить
        • >> самое главное - все объекты выделять динамически с new.
          хм, это точно сишник в кресты пришел а не джавист или пхпшник?:)

          а вы кстати знаете, что в джаву хотят завести объекты, живущие на стеке?
          Ответить
          • > хм, это точно сишник в кресты пришел а не джавист или пхпшник?:)

            ходят кучи книжек/этц как раз рекламирующие кресты в встроенщине.

            с другой стороны, какие зеленые выпускники каких курсов скорее все ничего кроме такого стиля и не видели.

            > а вы кстати знаете, что в джаву хотят завести объекты, живущие на стеке?

            лучше 20 лет поздно - чем никогда.
            Ответить
            • >>лучше 20 лет поздно - чем никогда.
              Теперь жабоёбы будут ломать голову над вопросом: "а где же мне разместить этот объект"?
              Ответить
              • шо?? ... т.е. кампилер сам догадыватся не будет? ... ну может еще через 20 лет.
                Ответить
                • Так сам он давно догадываеца, завезти хотят value types, когда ты будешь не ео указателю работать
                  Ответить
                  • > Так сам он давно догадываеца

                    ... а блин, может быть. я думал просто вечный дроч со стороковыми операциями, что бы в гц лишнего не сорить. а строки то там (как и крестовый стринг) динамические их на стек не положишь. или в жабу какую shortstring завезли уже?
                    Ответить
                    • >>динамические
                      Строки в жабе, если я верно помню, это честная обёртка вокруг массива char.
                      Массивы в джаве имеют информацию о размере (они не null terminated, там физически есть инфа).

                      Так что теоретически строку тоже можно сложить на стек, но это implementation details, программист про это думать не должен наверное
                      Ответить
                      • Они же иммутабельные... В итоге любой алгоритм который мало-мальски юзает строки порвёт тебе стек.
                        Ответить
                        • если он склеивает строки и если у меня нет хвостовой рекурсии то наверное порвет.

                          Но это вообще не вопрос строк: это вопрос стека и кучи, имхо. Если я знаю что нечто будет расти до неебических размеров то я ложу это на кучу, даже в няшненькой.

                          А вот
                          void foo() {
                          String pitux =  "pituh" + Integer.toString(getCurrentId());
                          System.out.print(pitux);
                          }

                          тут-то зачем pitux на кучу класть?
                          Ответить
                          • Ну тут оптимизнуть можно только если полностью заинлайнится Integer.toString(). Иначе откуда конпелятору знать, что там десяток символов а не мегабайт?
                            Ответить
                            • У копелятора может быть какой-то интринсик о том сколько чимволов может быть в десятичном представлении unsigned 32 битного Integer , не?

                              Но вообще я фантазирую, конечно: надо читать сырцы jdk, а мне лень.

                              В принципе это известный факт что иногда некоторые объекты jit может покласть на стек если сможет доказать что ссыль на них никуда не утечет.Делает-лион это для примера выше я хз
                              Ответить
                              • Кстати, интересно как вообще реализован Integer.toString(). Через стрингбилдер поди, чтобы сырую сишную функцию не дёргать. Или вообще лезет напрямую в кишки "иммутабельного" стринга...
                                Ответить
                                • http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/lang/Integer.java

                                  >> char buf[] = new char[33];
                                  >> return new String(buf, charPos, (33 - charPos));
                                  Ответить
                                  • > 33
                                    Код написан сишником, который решил оставить место под нолик?

                                    З.Ы. А, тьфу, это под знак.
                                    Ответить
                        • Вот в JS за счёт иммутабельности на словах и сокрытия от программиста всякой ненужной для решения задачи внутренней питушни вроде места, где хранится строка, а ещё за счёт JIT создался вычислительный рай как в функциональных языках, где ты пишешь то, что тебе надо для решения задачи, а оно внутри оптимизирует и раскладывает что нужно куда нужно.
                          for(var i=0, s=''; i<N; i++, s += 'a') // ко-ко-ко, s иммутабельная, O(N^2)
                          // на самом деле спокойно может быть O(N)

                          И это хорошо, что в местах, где сейчас нужна производительность, был впилен такой язык (тормозной по определению, с низким порогом вхождения). За счёт этого мы теперь имеем отличные движки с хитрожопейшими системами оптимизации опередившими своё время и внутренним компилятором, который из исходников готовит рабочий код за доли секунды (привет шаблонам C++).
                          Наконец с программой пердолится и выжимает все соки не человек, а другая программа. Никто из авторов движков не надеется, что на JS напишут хороший быстрый код, и не нагружают программиста деталями реализации.
                          А если позволять пользователю раскладывать переменные туда, куда он хочет их положить, придётся либо попрощаться с пирфомансом, либо мириться со временем и стоимостью разработки, ибо то же самое, что напишет на JS неумеха оператор шаблонизатора за час, дорогой опытный сишный оператор памяти выдаст за 100500 часов, а результат тот же.
                          Если уж такое делать, то стоит оставлять это как директивы компилятора (потом, когда все начнут писать на всякий случай какие-нибудь традиционные или устаревшие директивы, не слушать их по умолчанию и добавить второй комплект, третий, чётвёртый - как в GCC с inline), и чтобы без них всё работало автоматически.
                          Ответить
      • А внутри каждого элемента там инт и еще указатель. И этими руками он запускает кэшгринд.
        Ответить
        • Как всё-таки быстро сишники расслабляются увидев язык высокого уровня...
          Ответить
        • совсем не Data-Oriented Design, лол
          Ответить
    • > плюсы медленнее си
      Ну в общем-то логично. Плюсы - язык более высокого уровня.
      Ответить
    • влепил пинус.
      Ответить

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