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

    0

    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
    #include<iostream>
    
    void suka( void(*callback)( void(*)( void(*)() ) ) ) {
        std::cout << "Suka, ";
        callback( suka );
    } 
    
    void blyad( void(*callback)( void(*)( void(*)() ) ) ) {
        std::cout << "Blyad !!!" << std::endl;
        callback( blyad );
    } 
    
    int main() {
        suka( blyad );
        return 0;
    }

    ...

    Запостил: OlegUP, 20 Октября 2017

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

    • Попробуйте сигнатуру посложней.
      Ответить
      • Нахуй не надо писать типы в такой форме. Указатели на функции надо тайпдефать, тогда всё понятно.
        Ответить
        • Сейчас набегут старые сишники и будут кричать, что тайпдефы не нужны, потому что с тайпдефами сложно отличить сложный тип от скалярного.
          Ответить
          • Который тайпдефят даже указатель скаляра?
            Вспомнить виндовые тайпдефы с префиксом LP
            Ответить
        • Сделайте мне тайпдеф для функции, которая принимает указатель на функцию с такой же сигнатурой, как она сама.
          Ответить
          • А без тайпдефа это как записать? Просто из общих соображений:
            ? -> a
            = (? -> a) -> a
            = ((? -> a) -> a) -> a
            = ...
            Вот с "тайпдефами", но в хаски:
            newtype RArr to from = Arr { unarr :: from -> to }
            newtype Fix f = Fix { unfix :: f (Fix f) }
            
            type RecRArr to = Fix (RArr to)
            Ответить
          • К слову о споре "статическая питушня vs динамическая питушня".
            Пока статический питушок вычисляет тип и задействует математику, у динамического питушка всё работает, и он рвётся к более продвинутым абстракциям.
            typedef void (*cool_function_t) (void *);
            Ответить
            • Статический питушок уже понял, что дело — дрянь, но динамического питушка уже не остановить...
              Ответить
              • просто программа динамического питушка упадет когда-то потом, когда он уже уволится и это будут не его проблемы
                Ответить
                • И не упадет, а будет троллить пользователя сообщениями в духе "Уважаемый [object Object], на вашем счету осталось undefined рублей. Рекомендуем пополнить счет." А заказчик этого говна еще неделю будет ломать голову, почему все кастомеры называют его ебаным шарлатаном и настойчиво требуют гореть в аду.
                  Ответить
                  • Уважаемый undefined, у Вас осталось NaN рублей скорее:)

                    Но ты очень точно описал суть
                    Ответить
                  • И в какой-то момент программа ещё потребует приобрести змею.
                    Ответить
                  • Если быть честным, статический жабоеб выведет аналогичное

                    Уважаемый User@8172631, на вашем счету осталось null nullблей. Рекомендуем вам
                    java.lang.NullPointerException
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                    Ответить
                    • На самом деле нет. Контейнер сервлетов вернет 500ю ошибку, и пользователь получит хуй.

                      Кстати, нулизацию можно проверять статические. У Intellij есть аннотации nullable/notnull, а в котлине этовообще разные типы.
                      Ответить
                      • > Кстати, нулизацию можно проверять статические.

                        Это тебе сильно поможет, когда ты напишешь "на вашем счету осталось " + amount;
                        Ответить
              • Статический питушок подавлен теорией и мыслит ограниченными категориями. Он бы не смог сделать ideone потому, что неизвестно, остановится ли программа.

                У царя было три сына, у трёх сыновей - по 0..3 сына, а у них - по 0..3 сына и так далее.
                Картина из реального мира, которую заказчик требует описать в программе. Статический питушок уже сломался, а динамический - построил дерево на ссылках.
                Ответить
                • У статического питушка тоже есть деревья и ссылки. Зато динамический питушок сможет случайно записать царю в сыновья неведому зверушку.
                  Ответить
                  • И виртуальные методы есть, и reinterpret_cast с Object. Скатываются в динамику на каждом шагу. соринка_t не проскочит, а void*бревно легко пройдёт.
                    Ответить
                    • Статический питушок не обязан всегда принимать воид-звёздочку, а делая это, осознает все последствия. Динамический питушок порой не может даже потребовать определенное количество передаваемых аргументов, что обязывает его пердолиться с проверками количества аргументов и их типов постоянно. Динамически питушок быстро заебывается и кладет свой слабо типизированый андефайнед на всю эту вакханалию, и в конечном счете отстреливает себе обе ноги в пятницу вечером прямо на продакшоне.
                      Ответить
                      • Динамический питушок даже не сможет найти все места, где в поле объекта помещают значение... Что уж говорить о типе этого значения.
                        Ответить
                        • Более того, не всегда сможет найти все поля объекта. :3
                          Ответить
                          • Статический питушок тоже не всегда сможет найти все поля объекта, пока не запустит программу
                            auto o = static_perdolieren<game_of_life<42>>(x<1 0> + 1);
                            Ответить
                      • > Статический питушок не обязан всегда принимать воид-звёздочку, а делая это, осознает все последствия. Динамический питушок порой не может даже потребовать определенное количество передаваемых аргументов, что обязывает его пердолиться с проверками количества аргументов и их типов постоянно.
                        Ха-ха. Динамический питушок не обязан всегда использовать произвольное число аргументов, а делая это, осознает все последствия.

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

                        Вот мы и вся суть статического питушка. Как динамика - так грешно, как покажешь void*, так "мы не такие", а в коде всё равно Object и джвойная диспетчеризация. Как статика - так "смотри документацию, соблюдай контракты", как динамика - так "проверяй типы и значения".
                        Ответить
                        • > Динамический питушок не обязан всегда использовать произвольное число аргументов
                          А ну-ка, продемонстрируй мне это на твоем любимом JS. Только без пердолинга в духе иф-аргументс-сайз-хуяйз-кукарек.
                          Остальной твой высер - обычное кудахтанье, не имеющее ничего общего с реальностью. Въебал минус.
                          Ответить
                          • >> Динамический питушок не обязан всегда использовать произвольное число аргументов
                            > А ну-ка, продемонстрируй мне это на твоем любимом JS. Только без пердолинга в духе иф-аргументс-сайз-хуяйз-кукарек.
                            function sum(a, b) {
                              return a + b;
                            }
                            
                            alert(sum(1, 2));


                            > Остальной твой высер - обычное кудахтанье, не имеющее ничего общего с реальностью.
                            Зачем бугуртить, если не понял? Непонятный термин можно было и погуглить.
                            OK, вот на первый раз: https://ru.wikipedia.org/wiki/Контрактное_программирование
                            Ответить
                            • Статический питушок: весь контракт заэнфорсить не получается, ну пусть хоть какую-то часть конпелятор проверит.

                              Динамический питушок: весь контракт заэнфорсить не получается, да и хуй с ним, сам глазками всё буду проверять.
                              Ответить
                              • Ну, free(NULL), memcpy(NULL, NULL, 0), pow(0, 0) придётся именно глазками проверять в документации.
                                assert и throw как бы намекают, что всё равно придётся пердолиться в рантайме (if+throw ничем не лучше if+arguments.length+throw).

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

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

                                    Побочные эффекты тоже хрен сузишь (ну может быть, в C++ можно попробовать). Всё равно мануалы курить придётся до посинения. Хотя, в IDE статический питух лучше подсвечивается - это да, удобно.
                                    Ответить
                                • > всё равно придётся пердолиться в рантайме
                                  Т.е. тебя совсем не напрягает, что пердолинга в рантайме получается больше? Что чем раньше будет выявлена ошибка, тем дешевле будет её фикс? Что без 100%(!) покрытия строк юнит-тестами в динамике нельзя даже банальные опечатки отловить?
                                  Ответить
                                  • > Т.е. тебя совсем не напрягает, что пердолинга в рантайме получается больше? Что чем раньше будет выявлена ошибка, тем дешевле будет её фикс?
                                    Напрягает. Конечно, часто удобно удостовериться в том, что ошибок определённого рода нет.
                                    Я не против статических проверок, и C++ мне нравится.

                                    > Что без 100%(!) покрытия строк юнит-тестами в динамике нельзя даже банальные опечатки отловить?
                                    Справедливо для практически всех языков и программ. Фигурную скобку не там поставил - и всё.
                                    Ответить
                                    • > Справедливо для практически всех языков и программ. Фигурную скобку не там поставил - и всё.

                                      Овер 90% ошибок - всякого рода опечатки. Разница лишь в том, поймаешь ты их до или после запуска программы
                                      Ответить
                            • Т. е. ты не считаешь говном эквивалентность поведения sum(1, 2) и sum(1, 2, 3)? Типа кококо, ну я же написал им в своей ссаной вики, что там нужно два аргумента и что жс не говно, значит всё хорошо и очень удобно?
                              Ок.
                              Ответить
                              • Т. е. ты не считаешь говном, что strcpy(NULL, NULL) падает, а free(NULL) - нет? Типа кококо, ну я же написал им в своём сраном стандарте, что там нужно два аргумента и что они не NULL, значит всё хорошо и очень удобно, это же статическая типизация?

                                Расскажите уже Штульману про контрактное программирование, а то человек даже в статически типизированных языках на каждом сложении проверяет, что сумма операндов не приведёт к переполнению.
                                Ответить
                                • > Т. е. ты не считаешь говном эквивалентность поведения sum(1, 2) и sum(1, 2, 3)? Типа кококо, ну я же написал им в своей ссаной вики, что там нужно два аргумента и что жс не говно, значит всё хорошо и очень удобно?
                                  1023 прочитал про свое кококонтрактное программирование, возвел идею в абсолют, и решил, что сигнатуры вообще нинужны. Пусть переходит на баш, там вообще ни сигнатур, ни типов, прям контрактный рай
                                  Ответить
                                  • Stallman возвёл идею проверок в абсолют и перепутал вызов функции с проверкой пользовательских данных.

                                    Я не пойму, Stallman слишком молод, ничего не знает и считает себя королём мира, слишком стар, что для экономии мышлит шаблонами 70х годов (когда ему было 20 лет), либо просто тролль.
                                    Такое ощущение, что ему кто-то сказал, что JavaScript плохой и динамическая типизация - тоже плохая, вот он теперь ходит и всем это повторяет. И не имеет возможности анализировать ситуацию, всё динамическое стало угольно чёрным, а всё статическое - белым и пушистым.

                                    Программирование - это не только искусство, но и наука. Тут думать надо и оценивать плюсы и минусы, а не кукарекать, что JS говно.
                                    Ответить
                                    • Я думаю что статическая типизация в целом штука полезная: проверить что-то статически всегда лучше, чем узнать о проблеме в рантайме.

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

                                      Кто видел Java 4 -- тот поймет.

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

                                      Но современная стат типизация уже не так плоха, и потому ее по-тихоньку завозят в языки. Это pep-484 у питона, это пропозалы у JS (https://github.com/sirisian/ecmascript-types) и языки типа TypeScript, которые в JS компиляца.

                                      Кстати, динамическая типизация вовсе не означает отсутствие статической: например в java или c# типы проверяются и в рантайме, и в момент компиляции.

                                      JavaScript (в его нынешенем варианте) я, как и Stallman, считаю неудачным языком. У него убогая стандартная библиотека, его синтаксис непривычен для большинства программистов, нет нативных средств описания зависимостей и модулей, его прототипориентированность никому не нужна на самом деле: все эмулируют через нее обычное ООП (с костылями).

                                      Наконец тот факт что люди пишут языки, которые компилирются в javascript, говорит о том что большинство программистов JS не любят.

                                      Однако в JS 2015 внезапно ВСЕ стало сильно лучше. К сожалению без babel оно пока не везде работает, но в целом это говорит о том, что люди признали что у JS есть проблемы, и стали их исправлять.
                                      Ответить
                                      • > Просто раньше
                                        Когда? В млях все было.

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

                                          С функциональными ЯПами всё понятно: они опередили свое время на пол века, в них были вещи которые в мейнстримовых императивных появились только в нулевых:)

                                          >>Во-первых, означает.
                                          конечно же нет. Я даже пример привел.

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

                                          Не понял фразы. ЯП со статической типизацией может вообще ничего в рантайме не проверять. Си, например.
                                          Ответить
                                      • Вот это научный подход. Чётко, обоснованно, рассмотрены все стороны, разграничены мнение автора и факты.
                                        Stallman в последние дни только хейтит JS и переносит свои мысли об этом языке на программистов.

                                        Вот если бы были хорошие инструменты клонирования свойств и создания пустых объектов, ПП в JS было бы интереснее. Джвух фич (неявное прокидывание this в функцию и Function.prototype.setPrototype), как мне кажется, хватит для того, чтобы покрыть нужду в ООП.
                                        А возможность унаследовать только поведение бесценна. Можно, например, унаследовать квадрат от прямоугольника, и квадрат не будет хранить лишние поля.
                                        function A(x) { this.x = x; }
                                        A.prototype.getX = function(){ return this.x; };
                                        A.prototype.staticM = 8;
                                        
                                        function B(x, y) {
                                          A(x); /* вместо A.call(this, x); */
                                          this.y = y;
                                        }
                                        B.setPrototype(A); /* вместо
                                            B.prototype = Object.create.(A);
                                            B.prototype.conctructor = A;
                                        */
                                        B.prototype.getY = function(){ return this.y; };
                                        
                                        /* Возможность унаследовать только методы и статические поля
                                           не должна быть сломана! */
                                        function C(z) {
                                          this.z = z;
                                        }
                                        C.setPrototype(B);
                                        C.prototype.getY = function(){ return Math.sin(this.z); };
                                        C.prototype.getX = function(){ return Math.cos(this.z); };
                                        Ответить
                                      • > Наконец тот факт что люди пишут языки, которые компилирются в javascript, говорит о том что большинство программистов JS не любят.

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

                                        А схему стали делать, потому что от старинного лиспа их аж трясло.

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

                    Зато когда это нужно будет рефакторить то IDE пойдет вжопу, равно как и все другие питушки, потому что без запуска кода никто ничо не поймет
                    Ответить
    • prog.cpp: In function ‘void suka(void (*)(void (*)(void (*)())))’:
      prog.cpp:5:20: error: invalid conversion from ‘void (*)(void (*)(void (*)(void (*)())))’ to ‘void (*)(void (*)())’ [-fpermissive]
           callback( suka );
                          ^
      prog.cpp: In function ‘void blyad(void (*)(void (*)(void (*)())))’:
      prog.cpp:10:21: error: invalid conversion from ‘void (*)(void (*)(void (*)(void (*)())))’ to ‘void (*)(void (*)())’ [-fpermissive]
           callback( blyad );
                           ^
      prog.cpp: In function ‘int main()’:
      prog.cpp:14:17: error: invalid conversion from ‘void (*)(void (*)(void (*)(void (*)())))’ to ‘void (*)(void (*)(void (*)()))’ [-fpermissive]
           suka( blyad );
                       ^
      prog.cpp:3:6: note:   initializing argument 1 of ‘void suka(void (*)(void (*)(void (*)())))’
       void suka( void(*callback)( void(*)( void(*)() ) ) ) {
            ^~~~
      Накомпилировал за щёку, проверь
      Ответить
      • С вами был онлайн-компилятор ideone.com
        Благодарим за пользование нашим сервисом.
        Всего хорошего, идите нахуй.
        Ответить
        • https://ideone.com/vYTv6r
          В копилку об ideone. На стаковерфлоу выразили мнение, что портянка кода перед передачей в гцц препроцессится какой-то НЁХ на джсе, который интерпретирует "0" по-своему. Ideone пока молчат.
          Ответить
          • Скорее бага в обработке выхлопа программы. https://ideone.com/tHFBaw
            Ответить
            • Почти как жирный нолик на Говнокоде.

              [b]0[/b]

              Наверняка ideone писали пэхапэшники и проверяли пустоту выхлопа функцией empty.
              Ответить
            • Еще багу нашел https://ideone.com/9fCIs0
              Ответить
              • Лол. У ideone был целый HTML, чтобы выделить эту фразу, скажем, курсивом, когда она является метаданными.
                Ответить
                • У нас было два тега для жирноты (<b> и <strong>), 75 разных шрифтов, 5 тегов для других эффектов и бесконечное множество вариантов расцветок символов и фона. Не то, чтобы это был необходимый набор для выделения метаданных, но раз уж начал заниматься такой дурью, сложно остановиться.

                  Единственное, что у меня вызывало опасения, это CSS. Нет ничего более беспомощного, безответственного и испорченного, чем CSS-зомби. Я знал, что рано или поздно мы перейдём и на эту дрянь.
                  Ответить
                  • Кстати, а почему strong и emph именно в b и i отображаются, а не наоборот?
                    Ответить
                    • strong и em -- теги логической разметки, b и i -- физической. b всегда означает жирный текст, i всегда наклонный. strong означает усиление каким-то сбособом, в частности можно отображать в b -- выйдет усиление. em -- выделение каким-то способом, в частности можно отобразить в i -- выйдет выделение.

                      Можешь написать консольный браузер, который будет b рисовать жирным, а strong, например, капсом, стандарт ты соблюдёшь. Если b нарисуешь не жирным, а как-то иначе -- нарушишь.

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

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

                        Затем пришли сеточки, и всем стало похуй на семантику. Современная верстка напоминает табличную, и верстуны влегкую хуярят туда i и b. Причем i иногда вообще юзают не по на значению.

                        Веб попытался чуть-чуть побыть не говном, но потом он вспомнил что он всё таки веб и вернулся, так сказать, к дерьмоистокам
                        Ответить
          • https://ideone.com/KIzQMv
            Ответить
            • К сожалению, это проблема не Ideone.
              Ответить
              • Да, это проблема "Unicode".
                Ответить
                • Это проблема "C++":
                  https://ideone.com/fSytdu

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

                    https://ideone.com/Wp73wt

                    https://ideone.com/wUUroF
                    Ответить
                    • "C++" — единственный в мире язык с нативной поддержкой 256-ричных целочисленных литералов! Ура, товарищи!

                      https://ideone.com/2SxbDg
                      Ответить
      • Еще больше аргументов коллбеков богу коллбеков.
        Ответить
    • http://govnokod.ru/12071

      Я просто оставлю это здесь.
      Ответить
      • >>(*(*[])())()))
        Так вот ты какой -- современный промышленный язык программирования
        Ответить
        • Кстати, никак не могу найти говнокод, в котором совсем недавно обсуждали синтаксис крестошаблонных замыканий. Только помню, что к конструкции [](){} там ещё добавляется <>, а как целиком выглядит, не помню.
          Ответить
          • Это? http://govnokod.ru/23383#comment390667
            Ответить
            • Ещё давно было это: http://govnokod.ru/19230#comment311194
              Ответить
            • Похоже.

              Удалось скомпилировать:
              ([]<typename T>(T x){})(0);

              Кто придумает более короткий пример замыкания с шаблоном?
              Ответить
              • ([]<class T>(T x){})(0);
                Ответить
                • Ух, ты! Целые числа являются классами, как в Жабе!
                  Ответить
                  • в жабе классами являются только врапперы
                    примитивы -- нет

                    а вот в C# примитивы это вроде бы value types (кажется). Ну, методы у них есть
                    Ответить

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