Кресты / Говнокод #23679 Ссылка на оригинал

0

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

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

Запостил: g0cTb g0cTb, (Updated )

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

  • ava g0cTb # Ссылка на оригинал 0

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

    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;
    Ответить

    • ava Antervis # Ссылка на оригинал 0 ⇈

      автор статьи же не крестоблядь, а сишник с претензией на базовые знания плюсов.
      Ответить

    • ava Dummy00001 # Ссылка на оригинал 0 ⇈

      а это реальная проблема. я слышал обсуждения перевода встроенных проектов на кресты, и это был тихий ужас.

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

      "какой говняный язык, не будем им пользоватся." - почти буквальная цитата.
      Ответить

      • ava bormand # Ссылка на оригинал 0 ⇈

        А ещё STL в прошивку не влезает, а буст раздувает код.
        Ответить

        • ava Antervis # Ссылка на оригинал 0 ⇈

          std::vector<bool> потребляет больше памяти, чем экономит из-за того, что раздувает прошивку!
          Ответить

      • ava SemaReal # Ссылка на оригинал 0 ⇈

        >> самое главное - все объекты выделять динамически с new.
        хм, это точно сишник в кресты пришел а не джавист или пхпшник?:)

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

        • ava Dummy00001 # Ссылка на оригинал 0 ⇈

          > хм, это точно сишник в кресты пришел а не джавист или пхпшник?:)

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

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

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

          лучше 20 лет поздно - чем никогда.
          Ответить

          • ava SemaReal # Ссылка на оригинал 0 ⇈

            >>лучше 20 лет поздно - чем никогда.
            Теперь жабоёбы будут ломать голову над вопросом: "а где же мне разместить этот объект"?
            Ответить

            • ava Dummy00001 # Ссылка на оригинал 0 ⇈

              шо?? ... т.е. кампилер сам догадыватся не будет? ... ну может еще через 20 лет.
              Ответить

              • ava SemaReal # Ссылка на оригинал 0 ⇈

                Так сам он давно догадываеца, завезти хотят value types, когда ты будешь не ео указателю работать
                Ответить

                • ava Dummy00001 # Ссылка на оригинал 0 ⇈

                  > Так сам он давно догадываеца

                  ... а блин, может быть. я думал просто вечный дроч со стороковыми операциями, что бы в гц лишнего не сорить. а строки то там (как и крестовый стринг) динамические их на стек не положишь. или в жабу какую shortstring завезли уже?
                  Ответить

                  • ava SemaReal # Ссылка на оригинал 0 ⇈

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

                    Так что теоретически строку тоже можно сложить на стек, но это implementation details, программист про это думать не должен наверное
                    Ответить

                    • ava bormand # Ссылка на оригинал 0 ⇈

                      Они же иммутабельные... В итоге любой алгоритм который мало-мальски юзает строки порвёт тебе стек.
                      Ответить

                      • ava SemaReal # Ссылка на оригинал 0 ⇈

                        если он склеивает строки и если у меня нет хвостовой рекурсии то наверное порвет.

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

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

                        тут-то зачем pitux на кучу класть?
                        Ответить

                        • ava bormand # Ссылка на оригинал 0 ⇈

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

                          • ava SemaReal # Ссылка на оригинал 0 ⇈

                            У копелятора может быть какой-то интринсик о том сколько чимволов может быть в десятичном представлении unsigned 32 битного Integer , не?

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

                            В принципе это известный факт что иногда некоторые объекты jit может покласть на стек если сможет доказать что ссыль на них никуда не утечет.Делает-лион это для примера выше я хз
                            Ответить

                      • ava 1024-- # Ссылка на оригинал 0 ⇈

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

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

    • ava g0cTb # Ссылка на оригинал 0 ⇈

      А внутри каждого элемента там инт и еще указатель. И этими руками он запускает кэшгринд.
      Ответить

  • ava bormand # Ссылка на оригинал 0

    > плюсы медленнее си
    Ну в общем-то логично. Плюсы - язык более высокого уровня.
    Ответить

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

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓