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

    Комментарии (244) 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}");
                  Ответить
                  • показать все, что скрытоvanished
                    Ответить
                  • показать все, что скрытоvanished
                    Ответить
                  • показать все, что скрытоvanished
                    Ответить
                  • показать все, что скрытоvanished
                    Ответить
                  • хехехе, я за луа, милости прошу, к нашему шалашу
                    local petushok = {hello = 1, lua = 2}
                    
                    for k,v in pairs(petushok) do
                    	print(k.." - "..v)
                    end
                    Ответить
                    • Bent je pjetoech?
                      Ответить
                      • ахаха, а вот и нет.

                        В случае вопроса, обращенного именно ко второму лицу, "t" не нужно.

                        Именно вопроса
                        Именно к "ты/вы"
                        Ответить
                        • > Именно вопроса

                          Именно предшествования глагола существительному je.

                          als je een haan bent, stop je niet met kraaien

                          stop, не stopt
                          Ответить
                          • >Именно предшествования глагола существительному je.

                            а это бывает не только в вопросах?:)
                            я еще туда не дорос
                            Ответить
                            • ещё как дорос. 2nd verb order подразумевает что в простейшем предложении глагол всегда будет на втором месте, а остальное может двигаться в зависимости от конструкции, и если мы чем-нибудь вытесним подлежащее, то оно легко окажется после глагола

                              nu ben je een eend
                              Ответить
                          • Такое ощущение, что специально, чтобы «t» не оказалась перед «j».

                            У нидерландцев странновато звучат стечения звуков «sj» и «tj». Складывается впечатление, что они хотят произнести «ш» и «ч». Чем-то напоминает мутацию «си» и «ти» в японском.

                            P. S. В «als je» тоже наблюдается этот артефакт звучания.
                            Ответить
                            • Коровушка, кормят ли тебя костной мукой?
                              Ответить
                            • sj это среднее между "щ" и "ш"

                              alsjeblieft -- алщеблифт -- пожалста
                              meisje -- мейше -- девочка

                              А tj это ч

                              То есть все как-бы немного свдигается вперед

                              "je" это еще и уменьшительно-ласкательное, и я часто их слышу

                              kaart -- карта
                              kaartje -- карточка (карче).

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

                                У шведов ещё забавнее: sj читается как «одновременно звучащие [ш] и [х]». Именно так этот звук описан во всех учебниках.

                                https://forvo.com/search/sju/sv/
                                Ответить
                                • да, я бы тоже написал tjepoesjielo

                                  по ссылке я слышу мяхкую "х", типа "хю".

                                  Тут таких нет, но звук "сх" они любят, и часто он там, где у англичан "sh" (пишется он как "sch")


                                  schaap (схаап -- овца)
                                  schip (схип -- корабль)
                                  schoen (схун -- башмак)
                                  school (схоол -- школа)
                                  Ответить
                                  • > схавал овца
                                    Какой халяль)))
                                    Ответить
                                  • У немцев шаф, шип, шу, шуле. Кажется, это тот самый верхненемецкий сдвиг согласных.

                                    Лыжи у немцев будут «ши». Иногда пишут чисто по-немецки (Schi), а иногда в орфографии того языка, из которого позаимствовали это слово (Ski), но читают всё равно «ши». Вроде больше нигде «sk» у немцев так не читается.

                                    ***

                                    Кстати, на конце слов в sch нидерландцы теяют ch, поэтому Иеронима Босха современные нидерландцы зовут Бос.
                                    Ответить
                                  • > но звук "сх" они любят

                                    У немцев противоположная тенденция: они даже заимствованное из греческого Scheme читают как «шемэ». Более того, слово «шизофрения» — это искажённое немцами греческое («схизо» = «расщепляю» в переводе с греческого; у греков нету инфинитива). Вот уж насрали в вечность...
                                    Ответить
                                    • Отклонюсь от темы. Отсутствие инфинитива в греческом — это особый греческой багор. Грек вместо «я люблю кататься» скажет: «Я люблю, когда я катаюсь».
                                      Ответить
                                    • угу, немцы шекают (результат сдвига согласных), нидерландцы в ту сторону двинулись, но не дошли:

                                      spin -- паук
                                      spelen -- игарть
                                      overstappen -- пересадка

                                      Тут везде и не "c" и не "ш", а нечто среднее, и зависит от того, кто говорит.

                                      Но потому что глухая согласная идет следом.
                                      Если звонкая или гласная, то "s"

                                      snel -- быстрый
                                      sinaasappel -- апельсин
                                      slaapen -- спать

                                      тут везде чистое "c"
                                      Ответить
                                    • PS: По ту сторону линии Бенрата живут недердойче, они отличаются от хохсдойче в сторону нидерландского как раз
                                      Ответить
                  • показать все, что скрытоvanished
                    Ответить
                    • Я за "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
                        Ответить
                    • 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();
          })();
          Ответить
        • Ну, осемблерные вставки в JS - это конечно сильно...
          Ответить
    • но что этой мапой хотел сказать автор?
      Ответить
      • Наверное, он хотел подчеркнуть удобство итерирования по мапе в современных крестах:
        for (auto&& [k, v] : get_map())
        Ответить
        • > удобство ... в крестах

          хорошо.
          Ответить
          • В крестах удобства на улице.
            Ответить
            • Кресты для бичей, которые любят из раза-в-раз писать сборщик мусора и разводить клиента на бабки.
              Ответить
              • Как там в 90х?
                В С++ уже много лет как сделали «сборщик мусора», называется «RAII» и «умный указатель».
                Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • Но тем не менее, уже лет десять-пятнадцать писать явное управление памятью (new/delete/malloc/free) в коде на «C++» — моветон. Нормальный современный крестовый код вообще ни одной ручной аллокации не содержит.
                    Ответить
                    • показать все, что скрытоvanished
                      Ответить
                    • Самое неприятное в tracing gc, что они отучают погромиста убирать за собой.

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

                      Отсюда проблемы с незакрытыми коннекшнами, стримами. И всякие конструкты вроде try-with-resources.
                      Ответить
                      • показать все, что скрытоvanished
                        Ответить
                        • >зачем? зачем?
                          Действительно, если есть AutoCloseable.

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

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

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

                          Но он не работает с такими вещами как Lock или мьютекс.
                          Там по-прежнему нужно писать finally и делать release руками, как в старой-доброй сишке.
                          Ответить
                          • показать все, что скрытоvanished
                            Ответить
                            • >Думаю что диспозибл был сделан 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 на объекте рефлексией.

                              >Джависты, почему всё через жопу?
                              Жопа. Жапа. Жава.
                              Ответить
                  • >это всё таки не сборщик, а счетчик сцы-лок

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

                    Например в CPython счётчик ссылок это основной сборщик, а tracing (https://en.wikipedia.org/wiki/Tracing_garbage_collection) запускается иногда только для сборки островков циклических ссылок.
                    Ответить
                    • показать все, что скрытоvanished
                      Ответить
                      • 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.
                        Ответить
                        • показать все, что скрытоvanished
                          Ответить
                          • Самое интересное, что есть ещё царская сборка мусора.

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

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

                            Этот 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).
                              Ответить
                              • > The Stack Engine has a set of three dedicated adders

                                Сколько пафоса вокруг очевидной идеи про три сумматора, даже имя дали... Поди ещё и запатентовали, чтобы конкуренты не могли юзать?
                                Ответить
                                • >3 дня назад
                                  Какой некробамп )))

                                  Там прикол в другом: как Штеуд элегантно додумался совместить переименование регистров OoO с mov.

                                  А также неявно завёз концепцию нулевого регистра из RISC.

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

                                  Внутри x86-64 стал ещё больше RISC чем быдл до того.
                                  Ответить
                                  • Бамп, бамп, детка, бамп!
                                    Давай станцуем бамп!!
                                    Ответить
                              • Сначала кодеры пишут ксор иакс иакс, потом песчаный мост это оптимизирует. Перевернутый мир
                                Ответить
                                • Вай нот? Теперь не только кодируется компактно, но и работает быстро. nop они тоже вроде оптимизнули.
                                  Ответить
                                  • просто смешно: питухи нашли хак чтобы более легко обнулять регистр на нужной им части процессора, это заметили, и хак стал официальной идимой, оптимизированной

                                    Это как если бы я всё время забывал ключи, и вскрывал замок спичкой, а потом выпустили бы специальный замок со спичкой вместо ключа, потому что я уже привык

                                    В программировании вообще часто так бывает
                                    Ответить
                                    • Да этот "хак" как бы не в древних манулах был задокументирован...
                                      Ответить
            • В старых или в новых?
              Ответить
            • Это в сишке они на улице. А в крестах вокруг них построили стены и крышу.
              Ответить
    • Вопреки своей фамилии, Донда не славянин, да и назвали его так случайно. Имя Аффидавид он носит уже шесть лет, с тех пор как, покидая Турцию, написал требуемый властями аффидевит[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 потом соберёт старый. По сути те же самые конструктор+деструктор
                          Ответить
                        • Внимание: Ваше мышление зашкварено крестами.

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

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

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

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

                                      Ещё немного осталось потерпеть. Скоро туда structы завезут.
                                      Не бог весть что конечно. Но легковеснее чем обычные объекты.
                                      Ответить
                                      • показать все, что скрытоvanished
                                        Ответить
                                        • В них не будет ненужной объектной перепитушни (типа возможности писать 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.
                                          Ответить
                                  • Закон Мура не только действует на время выполнения программы как таковой, но и на доведение этой программы до ума.
                                    Раньше у компьютера не было времени, чтобы выполнить царскую программу, и она тормозила как по причине слабого железа, так и по причине недостатка автоматической оптимизации, а теперь у него есть время на эту самую автоматическую оптимизацию. Автомат может потратить время и из некоторого набора анскильных программ сделать царские, которые будут выполняться быстрее и при более долгом времени работы получат меньший оверхед.
                                    Ответить
                                    • Я один считаю что остановка действия закона Мура — очень хороший знак?

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

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

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

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

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

                                          >у меня 16 виртуальных цпу
                                          Разве что виртуальных. Типа SMT.
                                          Ответить
                                      • Я как пользователь тоже так считаю. В 2022 году буду думать о замене ноутбука 2011 года потому, что хромофоксы будут обмазываться всеми 8ГБ памяти и дрочить.
                                        Лет 20 назад компушню десятилетней давности встретили бы обмороком от удивления.

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

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

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

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

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

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

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

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

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

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

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

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

                                Неа.
                                Опять ошибка.
                                В скриптушне у него будут дикие проблемы с неясными типами.
                                То ли флоат, то ли инт. Гадай, оптимизируй.
                                Ответить
                                • Не, Сильному ИИ™ все эти анскильные «типы» будут не нужны. Программист будет просто формулировать задачу на естественном языке, а Сильный ИИ™ сам решать, какие там «типы» и какие «классы».
                                  См. начало 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 и использовать его. Более того, пока программа работает, за ней наблюдает жид и делает так, как удобнее именно здесь и сейчас, а не пытается предугадать все будущие варианты и скомпилировать универсальный царский код на все будущие запуски.
                                  Ответить
                                  • показать все, что скрытоvanished
                                    Ответить
                                    • Программист не анскилен, программист анскейлен.
                                      Если конпелятору докинуть вычислительной мощности и памяти, он увидит весь код целиком. С программистом так поступить нельзя.

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

                                          > компулятор взял, и сделал везде дабл. При этом в 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.
                                    Ответить
                                    • Ну, реализация и так довольно-таки тормозного «Питона» на тормозной «Яве»…
                                      Я даже боюсь представить, как это всё насилует память и сколько терабайт там выделяется-освобождается каждую секунду.
                                      Ответить
                                • Ну вот я зациклю объекты, а в одном из них файл окажется. Трейсинг гц хер знает когда запустится.

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

                              Может быть, программа хочет, чтобы файл был открыт, пока она жива.
                              Ответить
                              • Именно поэтому я за «RAII». Вышел из скоупа — умер. Хочешь жить дольше — заяви об этом явно соответствующим скоупом (ручное выделение памяти не рассматриваем, т.к. говно).
                                Ответить
                              • показать все, что скрытоvanished
                                Ответить
                                • Да. Пожалуй, стоит о таком явно говорить.
                                  Ответить
                                  • Это лучше, чем поселять в нём напрасную надежду, что он до сих пор кому-то нужен.
                                    Ответить
                          • показать все, что скрытоvanished
                            Ответить
                            • Надо при обнаружении похеривания ссылки на ресурс закрывать этот ресурс и бросать исключение. Рантайм без ИИ плохо соображает, когда действительно надо закрыть питушню.
                              Ответить
                          • Кстати вот пример как питухе(густ) аналог мув-семантики используется для проверки, что нет обращений к объекту после его деинициализации.

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

                            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 за скриптушачиьм говном.

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

                        Да. 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
                              Ответить
                          • Дорогие мои скриптухи
                            Незаметно как это бывает
                            И уже с чьей-то легкой руки
                            Сишку "С++"-ом называют
                            Ответить
                        • Типичное поведение программиста - использовать кривые модели, неверные предпосылки, а потом держаться за кучу говна, называя её архитектурой, весь последующий код выводя из неё.

                          Программисту сказали написать калькулятор. Программист сразу на всякий случай использовал матрицы. А вдруг потом понадобятся?
                          Попросили добавить корень - переписал под матрицы с комплексными числами. Отказаться от матриц не захотел. А вдруг кто-то ими воспользовался? Действительными числами обойтись не захотел У меня обработка ошибок иначе сломается, я лучше расширю домен.
                          Попросили добавить экспоненту. Матричную экспоненту реализовать было сложно, поэтому теперь по протоколу везде используются матрицы 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 олдфаг". Он имеет следующую структуру: новичок указывает на забагованные следствия и предлагает передалать, олдфаг игнорирует/привык к неверным предпосылкам, указывает новичку на правильные идеи и правильную логику, сам себя убеждает в правильности, ибо логично.
                      Ответить

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