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

    +1

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    #include <iostream>
    #include <map>
    
    std::map<std::string, int> get_map()
    {
        return {
            { "hello", 1 },
            { "world", 2 },
            { "it's",  3 },
            { "me",    4 },
        };
    }
    
    int main()
    {
        for (auto&& [ k, v ] : get_map())
            std::cout << "k=" << k << " v=" << v << '\n';
    
        return 0;
    }

    Запостил: govnokod3r, 15 Февраля 2020

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

    • Именно поэтому я против низкоуровневой хуйни

      Переведите на "Java Script"
      Ответить
      • (function() {
            function get_map() {
                return {
                    "hello": 1,
                    "world": 2,
                    "it's": 3,
                    "me": 4
                };
            }
        
            function main() {
                let map = get_map();
                for (let k in map) {
                    if (Object.prototype.hasOwnProperty.call(map, k)) {
                        console.log("k=" + k + " v=" + map[k]);
                    }
                }
            }
            
            main();
        })();

        Именно поэтому я против «JavaScript».
        Ответить
        • Какой "C++", Именно поэтому я за "Java Script"

          const obj = {'hello': 1,'world': 2,"it's": 3,'me': 4};
          Object.keys(obj).forEach((key) => console.log(`k=${key} v=${obj[key]}`));
          Ответить
          • Пф-ф-ф.
            const auto obj = std::map<std::string, int>({ { "hello", 1 },  { "world", 2 }, { "it's", 3 }, { "me", 4 }, });
            for (auto&& [k, v] : obj) std::cout << "k=" << k << " v=" << v << '\n';
            Ответить
            • JS и C++ соревнуются на количество спецсимволов на элементарное действие?
              Ответить
              • Ну это так, лёгкое обоссывание крестоблядей, у них ни шанса нет в любой битве против "Java Script"
                Ответить
                • >лёгкое обоссывание крестоблядей, у них ни шанса нет в любой битве против "Java Script"

                  Туда ли ты зашёл, скриптушок?!
                  Ответить
            • Добавить using namespace std, убрать сахарное auto и ничуть не хуже js.

              const map<string, int> = {{"hello", 1},  {"world", 2}, {"it's", 3}, {"me", 4}, };
              for (auto&& [k, v] : obj) cout << "k=" << k << " v=" << v << '\n';
              Ответить
              • И даже лучше: итерируемся сразу по ключу-значению, вместо питушарского «obj[k]».
                Ответить
                • Да на «Java Script» вообще говно какое-то нечитаемое. Из языков с «C»-подобным синтаксисом лучше уж с «до-диезом» сравнить:
                  var obj = new Dictionary<string, int> {{"hello", 1}, {"world", 2}, {"it's", 3}, {"me", 4}};
                  foreach (var (k, v) in obj) Console.WriteLine($"k={k} v={v}");
                  Ответить
                  • извини, но я за котлин
                    val foo = mapOf("hello" to 1, "world" to 2)
                    foo.entries.forEach {(k, v)-> println("$k --> $v")}
                    Ответить
                  • извини, но я за груви
                    def map = ['hello': 1, 'wrld': 2]
                    map.each{ k, v -> println "${k}:${v}" }
                    Ответить
                  • извини, но я за руби
                    foo = {"hello" => 1, "dd" =>2}
                    foo.each {|k,v| puts "#{k} -- #{v}"}
                    Ответить
                  • мильпардон, но мну за пёрл
                    my %foo = ("hello" => 1, "world" => 2);
                    for my $k (keys %foo) {
                    	print "$k -- ", $foo{$k}, "\n";
                    }
                    Ответить
                  • хехехе, я за луа, милости прошу, к нашему шалашу
                    local petushok = {hello = 1, lua = 2}
                    
                    for k,v in pairs(petushok) do
                    	print(k.." - "..v)
                    end
                    Ответить
                  • пардон, я за питон
                    foo = {"hello":1, "wrld":2}
                    for k, v in foo.items():
                        print(f"{k} -> {v}\n'')
                    Ответить
                    • Я за "Tcl":
                      array set foo {hello 1 world 2}
                      foreach {k v} [array get foo] {
                          puts "foo($k) = $v"
                      }
                      Ответить
                      • Ещё foreach в Tcl умеет итерироваться сразу по нескольким последовательностям:
                        array set foo {hello 1 world 2}
                        array set bar {kakoy 3 bagor 4}
                        
                        foreach {foo_k foo_v} [array get foo] {bar_k bar_v} [array get bar] {
                            puts "foo($foo_k) = $foo_v"
                            puts "bar($bar_k) = $bar_v"
                        }
                        https://ideone.com/5ld1n3
                        Ответить
                        • Поэтому я за «JSP».

                          Map map=Map.of("hello", 1, "world", 2, "it's", 3, "me", 4);
                          
                          <c:forEach var="entry" items="${map}">
                            k=<c:out value="${entry.key}"/> v=<c:out value="${entry.value}"/>
                          </c:forEach>
                          Ответить
                          • Я за JSPX.

                            К сожалению, JSPX не поддерживает незакрытые таги и мешать таги тоже не дает. То-есть ошибки верстки отлавливаются сразу, а не на третий день использования. Другими словами, JSPX автоматизирует проверку вел-форменности сайта, а это противоречит современным паттернам веб-разработки, которые гласят: "не нужно автоматизировать то, что можно сделать руками" и "лучше узнать об ошибке от пользователя, чем от средства разработки"

                            Потому JSPX не нужен и устарел
                            Ответить
                          • Страшнее только «XSLT».
                            Ответить
                            • По сути тот же angular ng-repeat.
                              Ответить
                              • иксесель, кстати, гомоиконен
                                Это хмл который служит для преобразования одного хмл в другой хмл и сам при этом хмл

                                можно сделать препроцессор на кслт для кслт

                                Слишком красиво для веб-макак, слишком сложно, пришлось вернуть им php
                                Ответить
                                • Да, именно поэтому я за «PHP».
                                  Ответить
                                • >иксесель, кстати, гомоиконен
                                  >Это хмл который служит для преобразования одного хмл в другой хмл и сам при этом хмл

                                  Ммммм.
                                  Мысль.

                                  На самом деле XSLT, по задумке очень годный. Функциональный, тьюринг-полный.

                                  Минус: он очень громоздкий (ибо xml).
                                  Потому любая композиция примитивов средствами языка выходит более громозкой чем обычная копипаста.
                                  Ответить
                                  • XML вообще вербозен. Почему не придумать другой синтаксис XML (похожий на JSON, YAML или TOML), но при этом с точно такой же семантикой?
                                    Ответить
                    • J наверное единственный из скриптовых не имеет встроенных хешмапов.

                      В нём единственная структура данных это массив.
                      Ответить
        • Циклы уже не модно
          (function() {
              function get_map() {
                  return {
                      "hello": 1,
                      "world": 2,
                      "it's": 3,
                      "me": 4
                  };
              }
          
              function main() {
                  Object.entries(get_map()).forEach(([k, v]) => console.log(`k=${k} v=${v}`))
              }
              
              main();
          })();
          Ответить
    • но что этой мапой хотел сказать автор?
      Ответить
      • Наверное, он хотел подчеркнуть удобство итерирования по мапе в современных крестах:
        for (auto&& [k, v] : get_map())
        Ответить
        • > удобство ... в крестах

          хорошо.
          Ответить
          • В крестах удобства на улице.
            Ответить
            • Кресты для бичей, которые любят из раза-в-раз писать сборщик мусора и разводить клиента на бабки.
              Ответить
              • Как там в 90х?
                В С++ уже много лет как сделали «сборщик мусора», называется «RAII» и «умный указатель».
                Ответить
                • Справедливости ради, это всё таки не сборщик, а счетчик сцы-лок
                  Ответить
                  • Но тем не менее, уже лет десять-пятнадцать писать явное управление памятью (new/delete/malloc/free) в коде на «C++» — моветон. Нормальный современный крестовый код вообще ни одной ручной аллокации не содержит.
                    Ответить
                    • Ну и что?
                      В ObjC и Swift тоже обычно нету ручного управления памятью, но и GC там нету, например, а есть референс каунтинг:)
                      Ответить
                      • Сойдёмся на том, что рнрвтп]окопег2 неправ.
                        Ответить
                        • Да, разумеется неправ. Неосиляторы любят ретранслировать тухлые мифы двадцатилетней давности: "си это сложно, там всегда течет память".

                          Я регулярно слышу "$SOMETHING это $BAD, там $КАКАЯТОХУЙНЯ" от людей, которые $SOMETHING в глаза не видели
                          Ответить
                          • Я видел "PHP", и это действительно говно.
                            Ответить
                            • Я тоже. Но это, скорее, исключение.

                              Вот пыхер например обычно ничего кроме пыха не видел, но на всякий случай считает, что все остальные языки не нужны
                              Ответить
                              • Доводилось видеть идейных пыхарей, которые натужно пытались осилить другие языки, но каждая попытка заканчивалась бугуртом от того, что там не так как в "РНР'. А, блять, ВЕЗДЕ НЕ ТАК КАК В" РНР". Вот и остаётся пыхомакака пыхомакакой, только на этот раз ещё более убежденной в правильности своего выбора.
                                Ответить
                                • Лучшее обоснование выбора пыха уже было на этом сайте

                                  --ПХП -- лучший язык для веба
                                  --А вы пробовали какие-то другие языки?
                                  --Нет, пока не было такой необходимости
                                  Ответить
                    • Самое неприятное в tracing gc, что они отучают погромиста убирать за собой.

                      Но при этом сами не умеют нормально и детерменированно освобождать ресурсы отличные от памяти.

                      Отсюда проблемы с незакрытыми коннекшнами, стримами. И всякие конструкты вроде try-with-resources.
                      Ответить
                      • +1, например.
                        Потом люди городят
                        https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/Disposable.java

                        Казалось бы: зачем? зачем?
                        Ответить
                        • >зачем? зачем?
                          Действительно, если есть AutoCloseable.

                          https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html

                          Причём особый багор, в и тут всё опять сделали через жапу.

                          try-with-resources (сахарок), конечно прикольно.

                          Но он не работает с такими вещами как Lock или мьютекс.
                          Там по-прежнему нужно писать finally и делать release руками, как в старой-доброй сишке.
                          Ответить
                          • Думаю что диспозибл был сделан 20 лет назад, до седьмой джавы.

                            А еще есть finalize, которым вообще надо пользоваться никогда.

                            Джависты, почему всё через жопу?
                            Ответить
                            • >Думаю что диспозибл был сделан 20 лет назад, до седьмой джавы.

                              Ээээ
                              https://github.com/JetBrains/intellij-community/commits/master/platform/util/src/com/intellij/openapi/Disposable.java

                              Commits on Aug 28, 2009

                              В 1.5 был просто Closable.

                              https://docs.oracle.com/javase/6/docs/api/java/io/Closeable.html

                              Проблема что он не был прикручен к Connection и другим нужным классам, где были методы close.

                              Помню как мне это надоело, я написал метод, и тупо вызывал close на объекте рефлексией.

                              >Джависты, почему всё через жопу?
                              Жопа. Жапа. Жава.
                              Ответить
                              • Думаю что это время, когда его опенсурснули. Intellij существует с 2000-го года, и хранился он тогда вероятно не в git, а в каком-нить cvs. Так что найти истоки будет сложно.

                                Initial release 1.0 / January 2001; 19 years ago
                                Ответить
                  • >это всё таки не сборщик, а счетчик сцы-лок

                    Счётчик ссылок принято считать особой формой сборщика мусора.

                    Например в CPython счётчик ссылок это основной сборщик, а tracing (https://en.wikipedia.org/wiki/Tracing_garbage_collection) запускается иногда только для сборки островков циклических ссылок.
                    Ответить
                    • >Счётчик ссылок принято считать особой формой сборщика мусора.
                      хм) Кем принято?
                      Я никогда не сталкивался с таким определением.
                      Ответить
                      • https://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf

                        Garbage collection is the process of runtime monitoring the life-time of objects and freeing them once they are no longer necessary. There are two main approaches to garbage collection: tracing [28] and reference counting (RC) [17].

                        Tracing garbage collection maintains a root set of live objects and finds the set of objects reachable from this root set. Objects not reachable from the root set are considered dead and their resources can be freed.

                        RC garbage collection, on the other hand, maintains a counter for each object, which tracks the number of references currently pointing to the object. This counter is actively updated as references are added and removed. Once the counter reaches zero, the object can be collected.
                        Ответить
                        • Ладно, принято
                          Ответить
                          • Самое интересное, что есть ещё царская сборка мусора.

                            Это самый простой и широкораспространённый тип.

                            И лично я выделяю его в отдельный класс.

                            Этот gc присутствует и в сишке, и алголе.

                            Он замечательно работает, пока программист не начинает вызывать *alloc.

                            У царского gc потрясающая скорость (указатель стека обычно двигает процессор), детерминированность, отсутствие задержек и фрагментации.
                            Ответить
                            • Причём stack-based gc сборщик единственный hardware friendly.

                              Уже лет 10 как в x86 есть move elimination, zero idiom elimination и stack engine.

                              Такие операции как mov; xor eax,eax; push и pop, просто выпиливаются не доходят до портов исполнения, даже не превращаются в МОПы.

                              Sandy Bridge recognizes instructions such as XOR, PXOR, and XORPS as zeroing idioms when the source and destination operands are the same. Those optimizations are done at the same rate as renaming during renaming (at 4 µOPs per cycle) and the architectural register is simply set to zero (no actual physical register is used).

                              x86 has dedicated stack machine operations. Instructions such as PUSH, POP, as well as CALL, and RET all operate on the stack pointer (ESP). Without any specialized hardware, such operations would would need to be sent to the back-end for execution using the general purpose ALUs, using up some of the bandwidth and utilizing scheduler and execution units resources. Since Pentium M, Intel has been making use of a Stack Engine. The Stack Engine has a set of three dedicated adders it uses to perform and eliminate the stack-updating µOPs (i.e. capable of handling three additions per cycle). Instruction such as PUSH are translated into a store and a subtraction of 4 from ESP. The subtraction in this case will be done by the Stack Engine. The Stack Engine sits after the decoders and monitors the µOPs stream as it passes by. Incoming stack-modifying operations are caught by the Stack Engine. This operation alleviate the burden of the pipeline from stack pointer-modifying µOPs. In other words, it's cheaper and faster to calculate stack pointer targets at the Stack Engine than it is to send those operations down the pipeline to be done by the execution units (i.e., general purpose ALUs).
                              Ответить
            • В старых или в новых?
              Ответить
            • Это в сишке они на улице. А в крестах вокруг них построили стены и крышу.
              Ответить
              • Как в России строят заборы:
                1. Пишут слово «ХУЙ».
                2. Вокруг него прибивают доски.
                Ответить
    • Вопреки своей фамилии, Донда не славянин, да и назвали его так случайно. Имя Аффидавид он носит уже шесть лет, с тех пор как, покидая Турцию, написал требуемый властями аффидевит[1] и вписал это слово не в ту графу анкеты, так что получил паспорт, аккредитивы, справку о прививках, кредитную карточку и страховой полис на имя Аффидавида Донды и, подумав, смирился, потому что, в сущности, не все ли равно, как кого зовут.
      Ответить
      • >Аффидавид
        Аффиный Давид.

        https://en.wikipedia.org/wiki/Affidavit
        Ответить
    • Исправьте, если не прав: при вызове функции здесь создаваемые пары будут копироваться в map, а не перемещаться, вызывая ненужную аллокацию и освобождение (первоначальная аллокация при создании строки очевидно нужная). На 14 по-моему будет так, а 17?
      Ответить
      • Вот во что это превращается (в 2000 символов не влезает):
        https://cppinsights.io/s/5d09f938
        Ответить
      • Нет, благодаря RVO (обязательном с «C++17»), коньструктору из «initializer_list» и другим оптимизациям карта сконьструируется однократно, как и строки-ключи. Причём «gcc» с «-O3» настолько царский, что пушает строковые литералы прямо в стек: https://gcc.godbolt.org/z/LWprNi, с 405-й строки.
        Ответить
      • Так это он наверно не RVO делает, а copy elision, либо что-то знает про строки.
        https://pastebin.com/JyXBFQex
        В M() по два ненужных copy, в Ms() по одному, добавление move() не убирает copy, только лишний move даёт. Лишние copy не убираются. (может make_pair, сейчас попробую...) При этом при инициализации пары в p() тоже ненужное copy, но в pm() оно успешно меняется на move (вероятно потому что это не initializer list, а brace initialization).
        Ответить
        • точнее при возврате карты RVO, а вот во время создания списка пар...
          Ответить
        • Да, использование move() в Mm() убирает одно ненужное копирование из двух, но оставшееся всё равно не убрать. У кого-то на др. компиляторах при запуске приведенного кода (функции M()) тоже 2 лишних копирования? Использование make_pair не помогает
          Ответить
          • std::initializer_list — питушня анскильная. Оказывается, из него нельзя деструктивно сконьструироваться: https://tristanbrindle.com/posts/beware-copies-initializer-list.
            Для пирфоманса остаётся делать так: https://wandbox.org/permlink/gCLMiBxrOJlepLGN (лишних копирований нет, move-коньструктор для STL-контейнеров — O(1) операция без аллокаций).

            И да, делать std::move() в местах, где будет RVO/NRVO, не надо: https://developers.redhat.com/blog/2019/04/12/understanding-when-not-to-stdmove-in-c/.
            Ответить
            • std::move - хипстерская питушня.
              Ответить
              • В «C++» не бывает хипстерской питушни, потому что хипстеры не пишут на «C++». Именно поэтому я за «C++».
                Ответить
                • >В «C++» не бывает хипстерской питушни, потому что хипстеры не пишут на «C++». Именно поэтому я за «C++».

                  Удваиваю!

                  >хипстеры не пишут на «C++»
                  Это один из самых весомых аргументов в пользу «C++».
                  Ответить
            • И эти C++тухи смеются над JSтухами, что те сами надумали себе проблем и борятся с асинхронностью.

              Когда нужно использовать какую-то фичу языка, и она не работает, программисту говорят, что виноват в этом он, и надо было читать вон те 300 страниц стандарта. Потом ему как маленькому ребёнку объясняют, в чём он не прав, и почему фича (точнее, баг) языка работает не так, как он ожидал. Рассказывается история языка и его "принципы".
              Когда человек говорит, что фича-то новая, и можно было её сделать как надо, ему отвечают, что он ничего не понимает, и вон те, те и те условия вынудили сделать так, и вообще, если бы сделали как надо, эта фича конфликтовала бы с ещё какой-то старой питушнёй.
              При попытке сказать, что питушню можно было выбросить или просто исправить, крестухи затыкают программиста и говорят, что кресты поддерживают совместимость. Им отвечают, что её и так всё равно уже сломали в случае вон с тем изменением. Крестухи тупят взор и говорят, что это вообще несравнимые понятия, и там было абсолютно другое дело.

              В логике есть понятие следования. Из истины следует истина, а из лжи - всё, что угодно. Обратно, если последовала истина, значит на входе было всё, что угодно, а если последовала ложь, - то на входе была ложь.
              Соответственно, если новая фича вышла говнистая, и это следует из принципов языка, значит принципы языка - говно и нуждаются в замене. Но крестухи считают наоборот. Стандарт непогрешим, свят и бесконечно правилен, а противоречия и следование из него говна - лишь надуманное кукареканье неподготовленного питузка, который должен наискорейше изменить свои мышление и систему ценностей, чтобы стандарт выглядел там логичным.
              Ответить
              • А причём тут вообще асинхроность?

                move-семантику (поглощение кишков других объектов) в кресты запилили чисто ради пирфоманса.
                Иногда она не срабатывает. И программа работает чуть медленее.

                «JS» и «пирфоманс» — оксюморон.
                Ответить
                • Асинхронность - багофича JS. Из-за неё объёмы кода и требование к интеллектуальному уровню программиста (в случае простого языка для школоло, да) повышаются.
                  Код на JS выглядит абсолютно не так, как на остальных языках, те же вещи выглядят сложнее.
                  Для борьбы с асинхронностью создаётся лапша коллбеков, промисы. Разрабатываются новые парадигмы и библиотеки, в язык впиливают генераторы и новые ключевые слова.
                  Код всё равно не становится таким же понятным, как в других языках, и новые конструкции - лишь сахарок над нагромождениями абстракций, призванных бороться с асинхронностью. То есть если что-то не сработает на уровне "async/await", программисту придётся спуститься на уровень генераторов, потом на уровень промисов, потом на уровень коллбеков. Только знаний async/await не хватит, для написания реального кода потребуется быть коллбековедом.

                  Аналогично с {}. Фича могла бы работать как надо, но из-за наслоений говна не работает, что выдаётся за правильное поведение.
                  Ответить
                  • Просто я не понял какое это отношение она имеет к обсуждаемой move-семантике, RVO и move elision.

                    Крестухи кмк делают важное дело.

                    И мне очень хотелось бы увидеть подобные питумизации в high-level языках с gc.

                    Для начала в том же хацкеле с принудительной иммутабельностью. А потом и во всяких jvm, v8 для COW.

                    Вместо бесконечного копирования при мутациях, ghc мог бы определять что исходное значение не используется, мутировать тот блок памяти и возвращать его.

                    Экономия на копировании и сборке.
                    Ответить
                    • Меня вообще первая ссылка взбудоражила. И оборот "деструктивно сконьструироваться", который для крестовика адекватен, а для человека со стороны - оксюморон.

                      Мув-питушня - дело интересное, но уж лучше бы она была автоматической. А то ты один раз забыл что-то дописать, и потом у тебя вся программа испортилась.

                      С введением мув-питушни увеличились количество категорий значений. Раньше было логично - питушня, у которой есть интересное для нас значение (rvalue) и питушня, у которой есть интересный для нас адрес (lvalue). Это хорошо мапится на внутреннюю структуру. Каждый, кто писал свой интерпретатор для простого языка с арифмопитушнёй и присваиваниями, автоматически и логично дошёл до темы lvalue и rvalue: некоторые особенные операции требуют помещения в стек адреса, а не значения.
                      В современных крестах теперь 100500 неочевидных категорий значений и кобенаторно большее число кобенаций эффектов от их взаимодействия. Как трёхмерная таблица типов для арифмушни в JS.
                      Пачку конструкторов добавили. А это уже в некотором смысле дублирование кода. Если класс поменялся, нужно менять не только все конструкторы (или, хм, в новых версиях разрешили переиспользовать конструкторы, не помню?), но ещё и дополнительный спецконструктор. Забыл это сделать - у тебя объект правильно создастся, правильно скопируется и неправильно переместится. И из-за вороха правил о том, когда какой конструктор выполняется, баг будет вылезать в неочевидных местах.
                      Ответить
                      • > у тебя объект правильно создастся, правильно скопируется и неправильно переместится. И из-за вороха правил о том, когда какой конструктор выполняется, баг будет вылезать в неочевидных местах

                        Как я понял никакого бага не будет. Там везде no leaks.

                        Просто компилер не сможет сделать RVO и лишний раз кишки скопирует.

                        Плюс вызовет констуктор для нового и деструктор для старого, уже не нужного.
                        Ответить
                        • Это если не писать новый ко-ко-конструктор. А если писать, то его нужно поддерживать.
                          Описанная мной питушня происходит при модификации класса, у которого уже есть конструктор копирования и конструктор перемещения.

                          Не укажешь конструктор перемещения - код будет недостаточно царским, иногда будет тормозить.
                          Укажешь конструктор перемещения - надо его поддерживать, а так как код царский, абстрагироваться не получится (из-за пирфоманса), будет два конструктора, которые почти такие же, но с различиями, которые оба надо будет поддерживать.
                          Ответить
                      • > для человека со стороны - оксюморон
                        Со стороны параши более высокоуровневых языков, в которых про все эти байтики и копирования не думают и текут — возможно. Для какого-нибудь сишника следить за копированием/перемещением/удалением — вполне себе норма.
                        Ответить
                        • «Высокоуровневые» языки
                          а) создают кучи говна на куче и гоняют только ссылки
                          б) при копировании и херинге исходного объекта обычно никогда и ничего не оптимизируют, а тупо плодят новые объекты, а gc потом соберёт старый. По сути те же самые конструктор+деструктор
                          Ответить
                          • ...но копирование это все равно поверхностное, а внутри объета все равно ссылки.
                            Ответить
                            • Ага. Не всегда конечно. Небольшие объекты (строки из примера) могут быть на стеке.

                              Плюс там в общем случае констукторы/деструкторы с непонятным содержанием. Они могут закрывать ресурсы и открывать их снова.

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

                                Кстати, копирования обекта у жабоёбов тоже нету, соответственно и копирующего конструктора тоже нет. Это все надо делать руками.
                                Ответить
                        • Внимание: Ваше мышление зашкварено крестами.

                          Следить за копированием/перемещением/удалением - полезно, кто-то это обязательно должен делать. Лично я - за то, чтобы это делал компилятор, т.к. он может посмотреть на программу целиком и понять, где что надо делать, а у программиста будет регулярный код в терминах бизнес-логики, а не в терминах вынужденного байтоёбства.

                          Но деструктивное конструирование не перестанет от этого быть оксюмороном. Два миллиона евро плюс два миллиона евро - это четыре миллиона евро, не важно, человек зарабатывает миллион, тысячу или сто евро в месяц.
                          Ответить
                          • Имхо, универсального подхода не существует.

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

                            ГЦ остановит систему на 3 секунды? Ну и похуй, пользователь получит рекламное предложение на почту на 3 секунды позже.

                            ЦПУ будет занят на 100% на время ГЦ?
                            Ну и похуй, чем еще должен заниматься xeon в датацентре?

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

                            А вот когда я пишу десктопную петушню, то все меняется.

                            ГЦ ест батарейку пользователя, докупить память он не может (современные макбуки этого не позволяют), время отклика 3 секунды означает для интерактивной программы, что она зависла.

                            Программист бы и рад помочь компилятру: сказать, когда ообъект освободится, и не заставлять его считать кучу питушни в ГЦ, но у него нету такого API.

                            И это я еще не затронул всякую ембеддед разработку.
                            Ответить
                            • Именно!
                              Универсальное решение, когда «программист» просто говорит конпелятору «сделай заебись», а конпелятор делает максимально быстрое, удобное и безопасное «заебись», бывает только в мире розовых пони и сильных ИИ. А наш мир, увы, несовершенен, абстракции текут, поэтому компромисс между скоростью разработки, высотой абстракций и скоростью выполнения будет существовать всегда.
                              Ответить
                              • >Следить за копированием/перемещением/удалением - полезно, кто-то это обязательно должен делать. Лично я - за то, чтобы это делал компилятор
                                > конпелятор делает максимально быстрое, удобное и безопасное «заебись»

                                Притом что крестокомпилятор и так изо всех сил оптимизирует.

                                И программист обычно на это не смотрит, пока профайлером не выяснит что оно мешает.
                                Ответить
                              • ну, c другой стороны компиляторы умнеют, и процессоры тоже.

                                30 лет назад сама идея написания чего-либо кроме скрипта разбора почты на скриптовой питушне звучала как лулз.

                                Теперь на тайпскрипте целый IDE написали.

                                Может быть в 2050-м году все будут писать на высокоуровневной питушне, и думать про плюсы так же, как сейчас думают про ассмеблер

                                Но пока что нет. Во всяком случае футпринты памяти у intellij и vscode (который во много раз тупее, хотя и быстрее) просто пиздецовые.

                                Просто введи в гугл "intellij is slow" и охуей.
                                Ответить
                                • > Теперь на тайпскрипте целый IDE написали.
                                  В наибольшей степени это заслуга закона Мура, чем развитием компиляторов. 30 лет идея программы для обмена сообщениями, занимающей гигабайт оперативы, звучала как несмешной анекдот. Но закон Мура упёрся в физику и более не работает. Так что увы.
                                  Ответить
                                  • разумеется, процессоры стали быстрее

                                    но и многие хардварные вещи тоже: раньше пямять была асинхрнной, нужно было открывать страницы каждый раз, не было конвеера, спекулятивного выполнения, кучи ядер итд

                                    со стороны криптушнии не было джит и пр.

                                    Просто например идея полуручной работы с памятью меня, например, не очень смущает: я всегда понимаю покинет ли мой объект стек, или нет.
                                    Всегда понимаю, когда он станет больше не нужен. Хочется иметь кнопку "компилятор, позволь решать мне". Но хуй: нет такой кнопки в джаве.
                                    Ответить
                                    • >Хочется иметь кнопку "компилятор, позволь решать мне". Но хуй: нет такой кнопки в джаве.

                                      Ещё немного осталось потерпеть. Скоро туда structы завезут.
                                      Не бог весть что конечно. Но легковеснее чем обычные объекты.
                                      Ответить
                                      • Структы будут всегда копироваться? типа этакий валуё обжект?
                                        Ответить
                                        • В них не будет ненужной объектной перепитушни (типа возможности писать synchronized(value)).

                                          >типа этакий валуё обжект?
                                          Да. Если структы равны, если все поля их равны. Типа memcmp

                                          https://openjdk.java.net/jeps/169


                                          There are optimizations which can eliminate object allocation in some regions of code. For example, objects can sometimes be "scalarized" into their component fields, if an escape analysis can be successfully carried out. However, such optimizations are limited in scope and applicability. For out-of-line calls, objects must still be boxed into memory, as long as existing Java reference semantics are enforced. Without new rules relaxing reference semantics, local escape analyses cannot be relied on to remove boxing overheads from objects, no matter how similar they are to primitive types.
                                          Ответить
                                          • Если что-то появилось в C#, то подождите 20 лет, и оно появится в Java:)
                                            Ответить
                                  • Закон Мура не только действует на время выполнения программы как таковой, но и на доведение этой программы до ума.
                                    Раньше у компьютера не было времени, чтобы выполнить царскую программу, и она тормозила как по причине слабого железа, так и по причине недостатка автоматической оптимизации, а теперь у него есть время на эту самую автоматическую оптимизацию. Автомат может потратить время и из некоторого набора анскильных программ сделать царские, которые будут выполняться быстрее и при более долгом времени работы получат меньший оверхед.
                                    Ответить
                                    • Я один считаю что остановка действия закона Мура — очень хороший знак?

                                      Наконец-то анскильные отбросы перестанут писать своё bloatware как попало.

                                      Ибо я думал что процесс раздувания софта уже никак не оставить. Поскольку будут появляться всё более мощные компьютеры, способные его переварить.

                                      В итоге у нас появляется тот же самый по функицоналу софт, но чудовищно обросший свистоперделками.
                                      Ответить
                                      • мур работает, просто он работает горизонтально.

                                        Уже сейчас у меня 16 виртуальных цпу, а скоро будет 64.

                                        Скриптухи конечно не могут в многопочтку без гонок, но всякая асинхронно-корутинная питушная им в этом сильно помогает

                                        зы: вирт хуесосил блоатваре еще в 1996-м, лол.

                                        А Таненбаум примерно тогда же писал, что раньше люди умели писать оптимизированные программы, но теперь это умение утеряно
                                        Ответить
                                        • >мур работает, просто он работает горизонтально

                                          Нет.
                                          1. Новые тех. процессы уже не делают транзисторы дешевле, т.к. требуют экспоненциального увеличения числа масок.
                                          2. Число производителей осваивающих новые тех. процессы сократилось с десятка до двух (samsung, tsmc).
                                          3. У великого и могучего штеуда дикие проблемы с новыми тех. процессами. Из-за этого фактически пятилетняя стагнация на рынке десктопов.

                                          Если бы не АМД, мы бы до сих пор видели очередной i5-100500 с 4мя ядрами за те же 200$.

                                          >у меня 16 виртуальных цпу
                                          Разве что виртуальных. Типа SMT.
                                          Ответить
                                          • но количество транзисторов-то все равно растет?

                                            >разве что виртуальных
                                            HT.


                                            Напиздел кстати, их 12. Реальных ядер 6.

                                            Coffelake i7.
                                            Ответить
                                          • Подтверждаю. Кстати, у «Threadripper 3990X» заявляется 64 реальных ядра (и 128 потоков). Стоит он, правда, как чугунный мост.
                                            Ответить
                                            • Пока да, но через 15 лет будет стоить как семечки
                                              Ответить
                                      • Я как пользователь тоже так считаю. В 2022 году буду думать о замене ноутбука 2011 года потому, что хромофоксы будут обмазываться всеми 8ГБ памяти и дрочить.
                                        Лет 20 назад компушню десятилетней давности встретили бы обмороком от удивления.

                                        > появляется тот же самый по функицоналу софт, но чудовищно обросший свистоперделками
                                        Иногда - даже хуже по функционалу.
                                        Тебе подкинули гигабайты памяти, гигагерцы, экраны получше, а ты отрисовываешь меньше кнопок, меньше текста, работаешь медленнее и тупее.
                                        Ответить
                                        • > В 2022 году буду думать о замене ноутбука 2011 года потому, что хромофоксы будут обмазываться всеми 8ГБ памяти и дрочить.
                                          ИЧСХ на российском рынке из недорогих будут модели с 6ГБ, за аналог 1000 долларов у половины будет 8ГБ.
                                          Ответить
                                        • > В 2022 году буду думать о замене ноутбука 2011 года

                                          Хаха. 11 лет это очень много. Спасибо физическим барьерам и частотному потолку.

                                          Вот в 90х и 00х компы устаревали со скоростью света, буквально за 2-3 года.
                                          А видеокарты и того быстрее. Помню купил середнячка, поиграл немного, а там смотришь, у тебя уже говно старое.
                                          Ответить
                                          • У меня нету воспоминания о таком уж безумном устаревании

                                            Первый пень 1993-го года выпуска вполне мог работать в 1999м.

                                            Третий пень 1999-го года выпуска вполне мог работать в 2005-м.

                                            А процы на 775-м сокете я встречал вплоть до 2013-го года, хотя конечно это были не первые процы 2006-го, но примено 2008-го



                                            Впрочем, речь конечно не об игровых компах, а об офисных
                                            Ответить
                                            • Я о временах когда частоты прыгали вверх и буквально каждые полгода выходила модель на 10% быстрее.

                                              И свежая винда тогда выходила каждые полтора-джва года. 95/98/98 SE/Me/2000/Xp. Просто голова кружилась.

                                              Это 90е и первая половина нулевых, пока интел не упёрлась в 4 ГГц и огромное тепловыделение. А MS не начала пилить висту.

                                              >Третий пень 1999-го года выпуска вполне мог работать в 2005-м.
                                              Да. Третий пень был годнотой, ибо первые P4 были тупым говном, которое P3 сливал в хламину.
                                              И в 2004 у штеуда были трабы с 90м тех. процессом.
                                              Ответить
                                              • Третий пень рвал четвертого, потому что соснул длинный конвеер (суперскалярный вроде назывался).

                                                Частоты прыгали правда: от 75 мегагерц у первого пня, до 650 у третьго за 6 лет

                                                Был еще социальный момент: в ту пору у меня денег было мало, и у знакомых моих тоже.
                                                Считалось, что супер-крутой комп стоит тыщу баксов, а зарплаты у людей были 100 баксов.
                                                Так что совершенно нормально было купить себе самый дешевый комп, и сидеть с ним 10 лет.

                                                Я помню, что у меня не шли многие современные игры, и это никого не удивляло:)

                                                Сейчас тоже можно сидеть на сенди бридже 2012-го года со встроенной графикой, и он будет вполне себе открывать вконтакте
                                                Ответить
                            • К слову сказать, не всё так плохо с GC. Всё же есть большая и маленькая сборки мусора. И сервер больше тормозит из-за доступа к БД и выполнения какого-то анскильного кода, чем от сборки мусора (её-то цари писали).

                              Хотя, соглашусь, что универсального подхода не существует.
                              Ответить
                              • >И сервер больше тормозит из-за доступа к БД и выполнения какого-то анскильного кода, чем от сборки мусора

                                Доооо.
                                На 4 гигабайтных кучах задержки бывали по 5 секунд. Это очень неприятно.
                                Ответить
                              • https://habr.com/ru/post/487116/.
                                Ответить
                              • Про базу данных согласен, но на десктопах (да и в интерпрпйзе) бд может и не быть.

                                Есть еще подход, когда тяжелую хуиту пишут на сишечке, а потом встраивают lua, и пишут на ней бизнес-логику не думая про байты.
                                Ответить
                          • Ваше мышление зашкварено абстракциями.

                            Как только в компилятор встроят сильный ИИ — он сразу же и будет смотреть на всю программу целиком. А пока что либо всё в куче и копируется, а-ля жаба, либо всё ручками.

                            Деструктивное конструирование, оно же конструирование при помоще move-конструктора — вполне себе нормальный термин (хоть и придуманный мной, да). Вот есть у тебя объект X, ты хочешь из него сконструировать объект Y (Y := X). На высоком уровне абстракции тебе действительно похуй, как оно там всё будет, главное, чтобы результат был. А как только эта операция начинает выполняться сотню миллионов раз в секунду — тебе сразу хочется, чтобы во время неё не было никаких лишний копирований или аллокаций. И тут уже приходится задумываться, где там у тебя что копируется, где перемещается и как используется.
                            Ответить
                            • >как только эта операция начинает выполняться сотню миллионов раз в секунду
                              Logical error.

                              О каких миллионах речь?
                              Обычное для скриптухов дело — сайты с 38ю записями.
                              Ответить
                              • Скриптух - не птица
                                [придумайте продолжение]
                                Ответить
                                • https://ru.wikipedia.org/wiki/Клинтух
                                  Ответить
                                  • ниухя не понял, чем он отличается от обычного голубя?
                                    Ответить
                                    • >> По окрасу имеет сходство с двумя распространёнными евроазиатскими видами — сизым голубем и вяхирем, однако в среднем несколько мельче обоих и имеет более короткий хвост.

                                      >> У клинтуха по сравнению с диким сизарём окрас более монотонный, со слабо выраженными полосками на крыльях и без белого пятна на спине. Если снизу посмотреть на взлетающую птицу, то можно увидеть, что испод крыла серый — значительно более тёмный, чем у сизого голубя и вяхиря, и по тону почти не отличается от такого же тёмного брюха. Вяхирь выглядит гораздо массивнее остальных двух видов, и к тому же выделяется белым пятном на боках шеи. На груди клинтуха развит розовато-винный оттенок, более ярко выраженный, чем у сизого голубя, но занимающий меньшую площадь, чем у вяхиря.

                                      Боюсь, что я тоже сходу не отличу. А с учётом того, что у обычного сизого голубя есть куча культурных пород разных окрасок, которые одичали и скрестились с дикими, задача определения вида становится непростой.
                                      Ответить
                                  • Нужно придумать вторую строку в рифму
                                    Ответить
                                • https://lh3.googleusercontent.com/proxy/xYMt93wsnJiZPd-VpYGtmLLBpolJ6a98VwEIIQgPRV2DcWC3pzHBI2v9e_IERXAs0900Jh90mTJdJYNgdJqVuaXY0fI6Sst5FbZpydDoIoRz-A

                                  Типа такой
                                  Ответить
                            • > Как только в компилятор встроят сильный ИИ — он сразу же и будет смотреть на всю программу целиком.
                              Это да. Но вот только в скриптушне он будет смотреть на программу как на говно и оптимизировать направо и налево, а в крестах - программа будет смотреть на него как на говно, и всё, что он сможет выдать - пачку ворнингов вида "программист, это ты серьёзно или ошибся?"
                              Ответить
                              • >в скриптушне он будет смотреть на программу как на говно и оптимизировать направо и налево

                                Неа.
                                Опять ошибка.
                                В скриптушне у него будут дикие проблемы с неясными типами.
                                То ли флоат, то ли инт. Гадай, оптимизируй.
                                Ответить
                                • Не, Сильному ИИ™ все эти анскильные «типы» будут не нужны. Программист будет просто формулировать задачу на естественном языке, а Сильный ИИ™ сам решать, какие там «типы» и какие «классы».
                                  См. начало http://lib.ru/FOUNDATION/question.txt.
                                  Ответить
                                  • Согласен.
                                    Только ответ ИИ может быть очень неожиданным.

                                    Мы когда-то с wvxvw это здесь обсуждали.

                                    ИИ может дать ответ, который люди просто не поймут. Типа вореции поехавшего.

                                    PS Концовка рассказа эпична.
                                    Ответить
                                    • 42.

                                      Да, рассказ охуенен. Причём в оригинале, ИМХО, даже круче: https://www.multivax.com/last_question.html.

                                      Я, кстати, за «Wolfram Alpha»: https://www.wolframalpha.com/input/?i=Can entropy be reversed%3F.
                                      Ответить
                                      • >ИИ может дать ответ, который люди просто не поймут. Типа вореции поехавшего.

                                        https://www.youtube.com/watch?v=YCIptc12bmU

                                        И вот прошло много много лет. и доктор стоит перед вратами рая . а на встречу ему выходит бог в синей олимпийке и говорит- Привет Юрий Генадьевичь а ведь тогда не поверил мне....
                                        Ответить
                                • Нет, наоборот же. В крестах будет написано int, float, а по факту надо double. Компилятор будет извиваться, чтобы сделать и быстро, и как сказал программист. В скриптушне можно по контексту догадаться, что нужен double и использовать его. Более того, пока программа работает, за ней наблюдает жид и делает так, как удобнее именно здесь и сейчас, а не пытается предугадать все будущие варианты и скомпилировать универсальный царский код на все будущие запуски.
                                  Ответить
                                  • Почему ты считаешь, что программист настолько анскилен, что вместо int напишет double, например?
                                    Ответить
                                    • Программист не анскилен, программист анскейлен.
                                      Если конпелятору докинуть вычислительной мощности и памяти, он увидит весь код целиком. С программистом так поступить нельзя.

                                      Например, стык библиотек. В одной инты, в другой флоаты, программе нужны даблы.
                                      Или всё то же проектирование. Раньше думали, что нужны инты, теперь понадобились даблы. Переписывать целиком долго.
                                      Ответить
                                      • и вот на стыке библиотек случайно затесался один флоат

                                        компулятор взял, и сделал везде дабл. При этом в 99% случаев нам нужен int.

                                        Умный программист поймет, что int быстрее дабла, и выкинет оттуда этот ненужный плавающий питуз.

                                        А в твоем случае программист этой проблемы даже не заметит. В итоге все станет медленее.
                                        Ответить
                                        • > В итоге все станет медленее.
                                          У оптимизатора скриптушни развязаны руки - он может как навредить, так и помочь.
                                          Зависит от мощности анализатора. Если, например, там делается много округлений или печатается целое число, можно догадаться, что нужен целый питух.

                                          > компулятор взял, и сделал везде дабл. При этом в 99% случаев нам нужен int.
                                          А вот так ведь и сама сишка делает, правда только локально. Если в выражении затесался флоат, всё зашкваривается в плавучку.
                                          Ответить
                                      • Поэтому надо ГОМОИКОНЫ писать обобщённый код.
                                        Ответить
                                    • Кстати, вот эти все gprsvalue и 50 оттенков инициализации только затрудняют понимание. Программист уже не знает, как при данной комбинации предпосылок написать самый быстрый вариант.
                                      Если же он пишет шаблон, всё ещё больше усложняется. Приходится работать в области классов типов или концептов, выделять общие операции, думать про perfect forwarding. Если писать фиксированный код, он будет сильно тормозить для неподходящих типов. Если писать шаблонный код, он будет понемногу тормозить для некоторых типов, надо будет специализации писать.
                                      Ответить
                              • Скорее в компилятор крестов его просто не встроят. Да и в JS тоже. Для сильного ИИ это всё слишком низкоуровневое говно.
                                Ответить
                            • > На высоком уровне абстракции тебе действительно похуй, как оно там всё будет, главное, чтобы результат был. А как только эта операция начинает выполняться сотню миллионов раз в секунду — тебе сразу хочется, чтобы во время неё не было никаких лишний копирований или аллокаций.

                              Ну вот я ожидаю, что в C++ при инициализации временными объектами не будет никаких копирований или перемещений. Объекту указывают на шконку поле, на котором он будет вызывать свой конструктор. И всё.

                              Копирования/деструкции/перемещения вовсе не должно быть, если инициализация - первое и последнее использование переменной, и тем более, если это анонимное выражение.

                              Так и только так должно быть в языке, где важен перфоманс.
                              Ответить
                              • Проблема в том, что поле, на котором ты вызываешь конструктор объекта, тоже может быть объектом, состоящим ещё из парочки объектов. И всё это должно быть правильно сконструировано, инициализировано, перемещено и деконструировано.

                                Ну и да, основная проблема initializer_list в том, что его разработка велась одновременно с move semantics, и последнюю не учитывала. А потом стало поздно фиксить, Комитет решил, что это несущественно… Ну, короче, как всегда виноваты люди.
                                Ответить
                                • По идее, проблемы должны были всплыть, когда initializer_list используют во время перемещения. Но если во время простого создания объекта - всё должно работать прозрачно.
                                  Ответить
                          • >деструктивное конструирование
                            Это означает всего-лишь что вызывается деструктор старого объекта (аналог: собрал gc) и конструктор копии.

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

                            И повторюсь: мне хотелось бы видеть использование такой методу за пределами крестов.

                            Например оптимизацию немутабельной мутабельности (ещё один оксюморон) в хацкеле.
                            Ответить
                        • Да ладно, эти ваши сборщики мусора только память чистить и умеют. Файлы, сокеты и т.п. один хер руками закрывать.

                          Именно поэтому я за кресты, где все ресурсы равны.
                          Ответить
                          • Да.
                            >https://govnokod.ru/26439#comment528165

                            В CиПитоне сборщик на счётчиках ссылок, они дескриптор закроют сами, как только он не нужен.
                            Ответить
                            • А слабые ссылки там есть? А то это "как только" может очень не скоро настать...
                              Ответить
                              • Неа. Там гибридный сборщик.
                                Счётчик ссылок собирает очевидное говно, а круговую поруку собирает уже tracing gc как в жабе.

                                Если файл открыли прочитали и вышли из метода, то питон его закроет, т.к. не осталось никиаких ссылок.

                                Проблема в том что такое решение непортируемое в другие реализации питона на яве/шарпе (jython и ironpython). Т.к. там анскильные gc без счётчиков.
                                Ответить
                                • > реализации питона на яве
                                  Ух, бля.
                                  Ответить
                                  • А что тут такого? Ну jvm.
                                    Ответить
                                    • Ну, реализация и так довольно-таки тормозного «Питона» на тормозной «Яве»…
                                      Я даже боюсь представить, как это всё насилует память и сколько терабайт там выделяется-освобождается каждую секунду.
                                      Ответить
                                      • джейпайтон и айропайтон мертвы и не нужны, проверь.
                                        Ответить
                                        • не верь, эта черепашка пиздит.
                                          Ответить
                                        • >проверь.
                                          Проверил
                                          https://www.jython.org/news

                                          Jython 2.7.2 beta (v2.7.2b3 February 2020)

                                          A further beta release is now available for Jython 2.7.2 at Maven Central. It is built and tested with Java 8 and tested against Java 11. This fixes bugs raised in response to v2.7.2b2 and updates certain JARs. Although past predictions of releases have not been very reliable, we predict a release candidate in the week beginning 24 February.
                                          Ответить
                                          • 2.7? серьезно? он два месяяца как депрекейтед
                                            Ответить
                                            • Лол, я думал это они про версию именно «Jython», а имплементируют они какую-то тройку… Пиздец.

                                              А вообще я почитал про него, кстати. Пишут, что оно нужно для быстрой интеграции с джавакодом; в частности, там вместо питоновских пакетов используются классы «Java».
                                              Ответить
                                              • нахуй этот кентавр нужен вообще?

                                                хочешь скриптовать под жывыэм -- бери груви: и синтаксис лучше, и в любой момент можно включить стат проверку, и скорость хорошая.
                                                Ответить
                                                • Ну, мало ли есть любителей подушить питона.
                                                  Ответить
                                                • В последний раз когда я запускал груви, оно тупило почище питона.
                                                  Но это было 10 лет назад.
                                                  Уж лучше взять скакалку или котлин.
                                                  Ответить
                                                  • Скорее всего, в ту пору груви нельзя было компилировать, и не было invokedynamic.

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

                                                    Я говорил про скриптовые языки. Если ты согласен ВСЕГДА компилироваться, то конечно лучше взять koтлин, хотя у груви есть некоторые фишки типа динамического диспатча, но это не всегда нужно.
                                                    Ответить
                                                • > кентавр
                                                  Таким должно быть всё.
                                                  Язык - это питушня для высказывания мыслей, а не жёсткая реализация. Пусть будет больше возможности высказать свои мысли.

                                                  Может быть, я хочу программировать веб страницы на сишке со сборкой мусора, а прошивку писать на питоне с ручным управлением памятью.
                                                  Ответить
                                                  • Пока крестушки возятся с конпеляцией, цари элементарных частиц пописывают скрипты на C++ и интерпретируют их.
                                                    Ответить
                                      • Так это реализации тормозили, а не язык. Пистон с жидом может и полетать, и хоть один разочек сверху харкнуть на сишкоцарей.
                                        Ответить
                                • Ну вот я зациклю объекты, а в одном из них файл окажется. Трейсинг гц хер знает когда запустится.

                                  Т.е. детерминированности, по факту, никакой.
                                  Ответить
                            • > как только он не нужен
                              Питушня. Это уже возня с побочными эффектами. С памятью ладно, там из побочных эффектов только недетерминированность malloc() == NULL, а тут может закрыть слишком поздно, а может - слишком рано.

                              Может быть, программа хочет, чтобы файл был открыт, пока она жива.
                              Ответить
                              • Именно поэтому я за «RAII». Вышел из скоупа — умер. Хочешь жить дольше — заяви об этом явно соответствующим скоупом (ручное выделение памяти не рассматриваем, т.к. говно).
                                Ответить
                              • >Может быть, программа хочет, чтобы файл был открыт, пока она жива.

                                так почему не сказать об этом явна?
                                Ответить
                                • Да. Пожалуй, стоит о таком явно говорить.
                                  Ответить
                                  • Это лучше, чем поселять в нём напрасную надежду, что он до сих пор кому-то нужен.
                                    Ответить
                          • Формально ты можешь закрыть сокет в деструкторе/фаналайзере, но на деле он может вызваться никогда.

                            Потому жабоебы плодят все эти свои using autoclosable, питонобляди -- свои with итд.

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

                            Компилер выдаёт ошибку если код обращается к объекту без кишков.

                            https://yoric.github.io/post/rust-typestate/
                            Ответить
                    • > в том же хацкеле с принудительной иммутабельностью
                      > оптимизацию немутабельной мутабельности (ещё один оксюморон) в хацкеле
                      Тут вообще из-за прозрачности ссылок у компилятора все карты на руках.
                      Такая питушня может прийти вместе с оптимизацией хвостовой рекурсии как обновление компилятора, а не как новая конструкция с новой философией, 50 оттенками rvalue, новыми конструкторами, амперсандами, хинтами и багами.
                      Ответить
                      • >Такая питушня может прийти вместе с оптимизацией как обновление компилятора

                        Да. Именно об этмо речь.
                        Но почему-то они пока не сделали такое. А разгадка проста: Хаскель-отребье, как и всякое другое отребье не может ничего родить. Оно может только воровать, врать и соревноваться с инвалидами. Очевидно, что с реальным си++ они соревноваться не могут.
                        Ответить
                        • Математики, сэр. У крестушков, если не изменишь язык, у компилятора останутся связаны руки. Надо действовать.
                          В хаскелях всегда есть возможность соптимизировать старое говно, которой можно воспользоваться в любой момент. Решение существует, пусть всё продолжает гореть.
                          Ответить
                          • >В хаскелях всегда есть возможность соптимизировать старое говно, которой можно воспользоваться в любой момент.

                            Это всё красиво звучит только на бумаге. Почему такой питумазции ещё нет?
                            А пока такой оптимизации нет на практике — хацкелисты анскильные отбросы.

                            >У крестушков, если не изменишь язык, у компилятора останутся связаны руки. Надо действовать.

                            В жабе вот тоже люди чухали голову и пришли к выводу что нужно менять язык.
                            Хотя казалось бы: уровень абстракции куда выше.

                            It is difficult to work with vector values from Java because they cannot be directly represented in Java code without creating a temporary object. A mutable object (often an array) can be created to hold the components of such a vector value, but this is merely a workaround, which does not qualify as direct representation of the value, since the same object will (in general) successively hold a series of values. Alternatively, an immutable object can be created, which qualifies as a direct representation, but each new value requires creating a new object. The costs are often high enough to discourage programmers from using the direct representation.

                            Посоны прямым текстом говорят: немутабельность это дорого.
                            Ответить
                            • Хаскели надо зажать в такую же ситуацию, как и жсы. Чтобы либо делаешь оптимизацию, либо толпа макак разрушает веб.
                              Ну и вообще, как мне кажется, хаскели - площадка для вкидывания идей. Нормальный язык не должен возводить какую-нибудь питушню в абсолют, иначе он становится неюзабельным. В хаскелях нельзя написать hello, world без спецзнаний в хитрых областях математики. Не говоря уже о дебаге принтфом, для которого нужно одно-два высших образования.

                              В жс красиво поступили с иммутабельностью строк. В итоге мы наблюдаем эффекты как линеаризации квадратичного кода (str += 'x';), так и хранения старой питушни (a = pituz.substring(10e6, 10e6+1)). И в целом оптимизация неплохо справляется с идеей иммутабельности.
                              Ответить
                          • И вот ещё
                            It should be emphasized that place-oriented programming in Java is an anti-pattern, because it blurs the correspondence between Java variables and application values. If a value is implicitly defined by being stored in two or more Java variables, there is no way to work with it directly as as single variable, method argument, or return value. The programmer is required to manage aliasable "places" to store the value components, as well as the values stored in them. Any optimizing compiler is hard-pressed to distinguish the two.

                            Local escape analysis could be extended (with heroic efforts) to interprocedural escape analysis, allowing methods to pass object fields in registers, delaying object creation perhaps indefinitely. Without new rules for permanently locked objects, the existing rules for field mutability and object identity tracking would require complex, probably unworkable, additional data to be passed between methods along with the object field values.

                            We could add new explicit tuple types to the JVM, providing a more explicit third option between classes and primitives.
                            Ответить
                          • >У крестушков, если не изменишь язык, у компилятора останутся связаны руки. Надо действовать.

                            Так можно тоже самое сказать о ECMA-скриптерах.

                            Для новых фич языка, типа деструктивных присваиваний жскриптухи вводят полностью новый синтаксис.
                            var a,b,c;
                            var arr=[1, 2, 3];
                            [a, b, c] = arr;

                            А в крестах посоны делают новый вызов.
                            ::array arr {1, 2, 3};
                            int a, b, c;
                            ::tie(a, b, c) = arr;

                            https://godbolt.org/z/RRmruC
                            Ответить
                            • В кресты тоже завезли auto [a, b, c] = arr, проверь.
                              Ответить
                            • Это вообще не факт, что про то. Это же синтаксиальный сахарок, а не отмена правил и UB.
                              В крестах у компилятора всё так же будут связаны руки, в скриптушне - всё так же развязаны.
                              Ответить
            • > std::printf
              Вся суть C++. Взять понятные термины и наговнякать поверх них какую-то питушню.

              Если был простой и понятный pitux, он станет "std::pitux".

              Можно добавить строку кода "using namespace std" и писать "pitux" вместо "std::pitux". Но оказывается, что "std::" сделано для того, чтобы можно было любое говённое именование в будущем объяснять "ну у нас же std:: стоит, что вы так кричите".

              Даже если импортировал питуха как "using std::pitux", намучился с "template <Type, Allocator> using std::pitux_vector" (который появился не так и давно по меркам C++) и избавил все символы от богомерзкого std::, оказалось, что после переписывания кода сверху остались лишние using std::pituz и using std::petix, которые никому не нужны, но никто об этом не знает.

              Люди читают код и без штудирования всех using не понимают, это просто какой-то отсебяшный pitux или гордый std::pitux.

              Чтобы не было лишней мороки, пишешь везде std::pitux. Код увеличился вдвое. Простая формула становится адом. E=mc^2 занимает три строки из-за обилия std::swimming_pituz, static_cast<std::swimming_pituz<32>>(std ::pituz_energy()) и std::pituz_square<std::swimming_pituz<32 >>.
              Ответить
              • >Люди читают код и без штудирования всех using не понимают, это просто какой-то отсебяшный pitux или гордый std::pitux.

                ::pitux ?

                https://ideone.com/vXNpTg

                Я не адепт крестов, но со стороны ваши набросы на С++ выглядят нелепо.
                Люди обсуждают move-семантику, и удаление лишнего копирования.
                А вы возводите несработавшую оптимизацию в разряд вселенской ошибки.

                Кстати, именно поэтому я обычно никогда не лез в С++ срачи. Поскольку я крестов не знаю и меня в них быстро сольют.
                Ответить
                • > Люди обсуждают move-семантику, и удаление лишнего копирования.
                  И тут оказалось, что std::inipitulizer_pituz вызывает какие-то копирования.
                  > возводите несработавшую оптимизацию в разряд вселенской ошибки.
                  В статье из-за этого код не скомпилировался.

                  > Кстати, именно поэтому я обычно никогда не лез в С++ срачи. Поскольку я крестов не знаю и меня в них быстро сольют.
                  Иногда полезно взглянуть на проблему со стороны. Один раз сольют, второй раз сольют, а в третий раз осознают, что им говорил человек с незамыленным глазом и выберут другой язык для программирования. Но там будут свои питушни, и свои сектанты.

                  Кресты, как и другие языки, вызывают привыкание. Иногда стоит представить, как бы пришлось объяснять кресты обычному человеку - скажем, бабушке или психиатру, который ещё не решил, здоров ты или нет. И тут сразу всплывают все эти острые углы и нелогичности, которые ты на автомате обходил и считал нормальными. А то иначе - всё нормально и логично. Святой стандарт и чёткие из него следствия.
                  Ответить
                  • >В статье из-за этого код не скомпилировался.

                    Ошибка компиляции — наименьшее из зол, которые могут приключиться с программой.

                    Я понимаю что в js можно писать как угодно и никто ругаться не будет. А код ёбнет уже потом, при выполнении.

                    >вызывает какие-то копирования
                    Эти копирования и деструкторы — пыль, по сравнению с тем какие кучи мусора вычищает gc за скриптушачиьм говном.

                    Тут люди вообще всё по стеку двигают.
                    Ответить
                    • джит вроде умеет доказать, что питузню никто не трогает за пределами стека, и тогда размещает её в стеке, разве нет?

                      Но вообще конечно гц (трейсирующий) -- та еще пораша.

                      Програмисту врут, что он может не думать про память. В итоге там футпринт на 4гб, потому что кто-то за ссылочку зацепился.

                      Я все таки за языки типа обжси как минимум: там хоть программист понимает, кто и на что указывает, и как выглядит дерево ссылок, и когда ссылку нужно делать weak. В результате футпринт меньше, и стопзеворлда нету, и программист получается более умным
                      Ответить
                      • >джит вроде умеет доказать, что питузню никто не трогает за пределами стека, и тогда размещает её в стеке, разве нет?

                        Да. escape analisys в 6ой яве появился экпериментально.
                        Я тогда его включил, получил просадку пирфоманса.
                        В 7ой вроде допилили, но я не проверял

                        https://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/
                        https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#escapeAnalysis
                        https://minborgsjavapot.blogspot.com/2015/12/do-not-let-your-java-objects-escape.html

                        >гц (трейсирующий) -- та еще пораша
                        >В итоге там футпринт на 4гб, потому что кто-то за ссылочку зацепился.
                        Ага. Или просто gc влом собрать мусор.
                        Ответить
                        • это контринтуитивно
                          Почему так? Что говорит Шипилёша?

                          Ты же не хочешь мне сказать, что если я создам объект с двумя интами и передам его в функцию, то он создастся на куче?
                          Ответить
                          • Вам какие инты: инты или Интежеры?
                            Ответить
                            • разумеется я про примитивные инты
                              в современно колковешнене они вообще в регистры влезут, нет?

                              Я врапперами все понятно
                              Ответить
                    • Ну вот Вы начинаете как настоящий крестушок объяснять, что это всё логичное. Оно логично, но предпосылки говённые.

                      > Эти копирования и деструкторы — пыль
                      Это initializer list. То есть питушня для инициализации объектов.
                      Питушня для инициализации должна сразу наполнять поля объекта, а не создавать временные объекты ко-ко-копировать что-то.
                      Если инициализационная питушня в царском языке (где следят за лишними копированиями, т.к. нужен пирфоманс) вместо, грубо говоря, placement new в полях объекта делает какие-то манипуляции и в теории сливает пирфоманс, то она просто дефективная, её надо переделывать.
                      Ответить
                      • >Питушня для инициализации должна сразу наполнять поля объекта, а не создавать временные объекты ко-ко-копировать что-то.

                        Расскажите это хацкелистам с немутабельностью и ленивостью.
                        Когда простейшая программа приводит к out of memory.

                        >как настоящий крестушок объяснять, что это всё логичное
                        Есть огромная разница между некорректным поведением программы, и её недооптимизацией.
                        Ответить
                      • Ты просто мыслишь на слишком высоком уровне для крестов. «Initializer list» — это не «питушня для инициализации», это просто объект. То, что из-за кучи легаси и вообще странных решений в проектировании его сделали кривым говном — ну, C'est La C++.
                        Ответить
                        • Вопрос: а в сишке как-то можно добиться move-оптимизаций?
                          Ответить
                          • А какие именно move-оптимизации ты хочешь в сишке?
                            RVO и copy-elision, например, там есть: https://gcc.godbolt.org/z/mcCLhe.
                            Ответить
                            • Да я так подумал и понял что в вся свистопляска с мове-семантикой сделана чтобы убрать лишние конструкторы/деструкторы. Которых в сишке просто нет. Плюс в сишке нет тупых ограничений и «копирующих питухов», потому компилеру никакие гарантии не нужны.

                              Потому я за «сишку»

                              >RVO и copy-elision, например
                              А если там struct вложенный в struct? Мы возвратили внутренний struct, а внешний вышел за скоуп и похерился. Оно и такое сдюжит?

                              >А какие именно move-оптимизации ты хочешь в сишке?

                              Из совсем фантастических вещей: схлопывание malloc, memcpy и free.
                              https://govnokod.ru/15928#comment231366
                              Ответить
                          • Дорогие мои скриптухи
                            Незаметно как это бывает
                            И уже с чьей-то легкой руки
                            Сишку "С++"-ом называют
                            Ответить
                            • место для шутки про

                              требуется c/c++/c# программист
                              Ответить
                              • Я шуток не понимаю. Именно поэтому я за "PHP".
                                Ответить
                        • Типичное поведение программиста - использовать кривые модели, неверные предпосылки, а потом держаться за кучу говна, называя её архитектурой, весь последующий код выводя из неё.

                          Программисту сказали написать калькулятор. Программист сразу на всякий случай использовал матрицы. А вдруг потом понадобятся?
                          Попросили добавить корень - переписал под матрицы с комплексными числами. Отказаться от матриц не захотел. А вдруг кто-то ими воспользовался? Действительными числами обойтись не захотел У меня обработка ошибок иначе сломается, я лучше расширю домен.
                          Попросили добавить экспоненту. Матричную экспоненту реализовать было сложно, поэтому теперь по протоколу везде используются матрицы 1x1, матрицы других размерностей не тестируются, их использование приводит к падению программы.
                          Код стал тормозить. vector<vector<complex>> оказался медленнее double. Избавиться от матриц нельзя. У нас весь код завязан на матрицы!
                          В качестве оптимизации было решено отнаследоваться и сделать class MatrixDouble с одним double внутри, виртуальными методами и полным интерфейсом матрицы (который не выполняет протокол матрицы для размерностей 1x1).

                          В итоге код полностью завязан на матрицы, ничего матричного не считает, и любое изменение должно быть реализовано исходя из работы с матрицами, которые работают как числа.
                          Ответить
                        • > мыслишь на слишком высоком уровне для крестов
                          > «Initializer list» — это не «питушня для инициализации», это просто объект
                          Но ведь всю эту психозу накидывают для того, чтобы можно было писать быстрый код и сливать скриптушков? А в итоге у скриптушков получаются более быстрые и дешёвые программы, т.к. программист занят бизнес-логикой, а не пердолингом с языком, а у компилятора не связаны руки архаичными правилами, которые программист должен всегда держать в голове.
                          Ответить
                          • Как раз initializer_list накидали для того, чтобы можно было быстро писать код.
                            Более того, уровень просадки пирфоманса от кривой реализации initializer_list настолько мал, что для скриптушков такие временные промежутки просто незаметны — у них ГЦ работает на пару порядков дольше.
                            Ну и наконец, пропозал с фиксами уже есть: http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0065r0.pdf.
                            Ответить
                  • Я считаю move-семантику одним из лучших нововведених завезённых в с++11.

                    Благодаря ей кресты могут уделывать сишку* при работе на стеке.

                    Царский пирфоманс и stack based gc (https://govnokod.ru/26439#comment528179) во все поля.

                    *Поправьте если ошибаюсь. Не знаю, есть ли в сишке какие-то гарантии для компилеров, чтобы они могли выкидывать копирования
                    Ответить
                    • Это так везде с подобными языками. Всегда хорошие идеи, всегда запятнаны какой-то питушнёй.

                      Структура C++-подобных языков:
                      1. Неверные предпосылки и старое говно
                      2. Хорошие новые идеи
                      3. Логически корректный вывод говённой реализации 2 из 1

                      Все хорошие идеи должны пройти логически корректный вывод из неверных предпосылок. По-отдельности всё логично: и идеи хорошие, и логика логичная. Но из-за неверных предпосылок всё скатывается в говно.

                      Посмотрите любой срач "новичок vs олдфаг". Он имеет следующую структуру: новичок указывает на забагованные следствия и предлагает передалать, олдфаг игнорирует/привык к неверным предпосылкам, указывает новичку на правильные идеи и правильную логику, сам себя убеждает в правильности, ибо логично.
                      Ответить

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