1. Си / Говнокод #18694

    −11

    1. 1
    2. 2
    3. 3
    #ifndef _USE_MATH_DEFINES
    #define M_PI           3.14159265358979323846
    #endif

    Нельзя было сразу M_PI проверять?

    Запостил: 3_dar, 08 Сентября 2015

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

    • Как-то ты изменился, @3_dar. Округлился, огрубел. Почти что и не узнать.
      Ответить
      • Лол
        Ответить
        • Мне просто твой ник понравился, и я решил округлить :D
          Ответить
          • Был пидар, стал тридар?
            Ответить
            • эй, ты спиздил мою шутку! Указывай авторство, пидар
              Ответить
              • То есть если я нашел рубль, который бы нашел ты если бы я не нашел его до тебя - то я его у тебя спиздил?
                Ответить
                • kegdan в http://govnokod.ru/18694#comment297686 написал:
                  >> kegdan 14 часов назад # 0
                  >> Развели тут - пидар, тридар...

                  3_14dar в http://govnokod.ru/18694#comment297735 написал:
                  >> 3_14dar 3 часа назад # +1
                  >> Был пидар, стал тридар?

                  11 часов разницы, Карл
                  Ответить
                  • Ну тем более, твое авторство сохранено,не нервничай.
                    Ответить
      • А ведь я не заметил разницы до Вашего комментария. Только немного удивился, зачем ему сишка.
        Ответить
    • Развели тут - пидар, тридар...
      Ответить
    • Проблемы ёбаной Студии.
      Каждый раз надо в новом проекте прописывать дефины, которые я до сих пор запомнить не могу
      _USEMINMAX или USE_MIN_MAX?
      Ответить
      • Да блин, сделай уже себе какой-нибудь stdafx.h со всей этой сранью...
        Ответить
      • >в новом проекте прописывать
        В вашей сраной студии нельзя сделать шаблон для новых проектов? Алсо студия для си же говно?
        Ответить
        • Ну да. С99 они так и не осилили. А плюсы в последних неплохо сделаны.

          Правда без визуал ассиста или решарпера для крестов у неё довольно убогий редактор - нету рефакторинга, нормальной навигации и т.п.
          Ответить
          • >нету рефакторинга, нормальной навигации
            Ctrl+click (перейти к определению) не работает? Бля, нахуй она нужна?
            Ответить
            • Переход к определению есть. Но вот например "найти все использования" нету. А хочется.
              Ответить
              • А в вашем долбоси с его макросами это возможно? Разраб того самого пиаремого на кабре анализатора писал, почему они не стали анализировать какую-то библиотеку.
                Ответить
                • Вполне. IDE знает настройки проектов. Значит может и все макросы раскрыть как положено (для выбранной в данный момент конфигурации, само собой).

                  Там ведь даже код внутри #ifdef серым подсвечивается, если он не будет компилироваться в текущей конфигурации.
                  Ответить
                  • http://habrahabr.ru/company/pvs-studio/blog/213969/#comment_7355421
                    Ответить
                    • Ну так это человек не выдержал копания в макроговне и сдался, когда пытался сделать какие-то выводы по выхлопу анализатора?
                      Ответить
                      • Так а в чем там проблема-то? Статический анализ работает, но как-то не так?
                        Ответить
                        • Ну выдал анализатор хуеву тучу логов. Дальше их надо читать и искать где ошибка, а где ложная сработка. А там ехал макрос через макрос. Вот у чувака нервы и сдали.
                          Ответить
                          • >Ну и их единорог заточен под вижуалку и её стандартную либу. А на проектах для других компиляторов валит кучу false positive.
                            вовремя ты потер. Единорог работает под вижуалкой, а анализирует что хошь

                            Не повлияет этот ехал макрос через макрос на качество статического анализа IDe?
                            Ответить
                            • > анализирует что хошь
                              Не совсем. У него подавление ложных сработок именно под вижуалку, её либу и их особенности заточено. Они там сами писали, что дохуя мусора выдаётся на совсем безобидных конструкциях, когда либц разбирали.

                              Макросы элементарно раскрываются. Трабла в том, во что они раскрываются. После них же остаётся куча мусора типа 1 == 1. И весь этот мусор как раз попадает в выхлоп анализатора. И надо все такие случаи для известных макросов давить. Для макросов от Майкрософта они это сделали. Для гццшных - нет. Так что на качество анализа влияет - больше ложного мусора в результатах.

                              Суть анализа же не в том, чтобы выбесить программера миллионом нахуй не нужных предупреждений. А чтобы среди них остались, по возможности, только реальные проблемы а не шлак от раскрытия макро и шаблонов.
                              Ответить
                              • Ну хз.
                                Ответить
                                • Почитай статью как они либц разбирали. Посмотришь, в какую срань там раскрылось банальное strcmp.
                                  Ответить
                                  • Может, glibc а не libc? http://habrahabr.ru/company/pvs-studio/blog/213969/ это?

                                    Ох еб, они там вручную расставляют костыли, где материться на определенные конструкции, а где нет аки мс в винде 3.1 с цивилизацией.
                                    Ответить
                                  • >хочу обратить внимание (прежде всего других людей), что «мало воды в предупреждениях» — это результат очень долгой и сложной доводки анализатора под конкретный компилятор (VisualC++) и конкретную платформу. Как только анализатор запускается без такой доводки, скажем в гипотетическом линуксе — из него вода льется как из дырявого ведра.
                                    Все что нужно знать о качестве статических анализаторов для C(++)
                                    Ответить
                    • >Однако PVS-Studio и сейчас неплохо разбирает код. Исключение составляют сложные шаблоны. Однако в сложных шаблонах почти нечего искать или непонятно, как выдать разумное диагностическое сообщение. Поэтому, качество анализа практически не зависит от полноты разбора шаблонов.

                      как это понимать? Качество анализа практически не зависит от полноты разбора шаблонов, потому что мы их все равно не разбираем?
                      Ответить
                      • "Мы не умеем разбирать шаблоны, так что вам это не нужно." Маркетинговый ход.
                        Ответить
                        • Мы не умеем (и никто не умеет) разбирать шаблоны, так что enjoy your aids. Это нормально. Не просто так люди юзают языки со строгой статической типизацией. А про не нужно - да, звучит как НИНУЖНО, кококо.
                          Ответить
                          • Ну вот допилят в крестах концепты - вроде бы можно будет проверять шаблоны, причём даже сам компилятор сможет это делать. Ну и бустовские сообщения об ошибках на 10 экранов станут чистыми и понятными.

                            Там шаблон будет уже не с утиной типизацией, а что-то типа параметр N должен удовлетворять концепту "целое число", а параметр T - концепту "объект, который можно скопировать". Ну и соответственно в момент описания шаблона компилятор проверит, что ты не делаешь с параметрами ничего лишнего, что не описано в этих концептах. А в момент подстановки проверит, что в качестве параметров не передали левую хуйню, не подходящую под концепт.
                            Ответить
                            • Почему бы не перейти от концепции SQL инъекции, пардон, инъекции исходников, к работе с AST? Отпадут костыли которые делают чтобы что-то куда-то не неправильно вставилось.
                              Ответить
                              • Иньекция исходников это макросы.

                                А шаблоны и так уже на уровне AST работают. Просто у них утиная типизация. Вот, к примеру:
                                template <typename T>
                                size_t getSizePlusOne(const T & t)
                                {
                                    return t.size() + 1;
                                }
                                Когда компилятор читает описание шаблона, он понимает, что T - какой-то тип. И ничего больше о нём не знает. Кроме совсем базовых проверок тут ничего сделать нельзя (а вижуалка, емнип, нарушает стандарт и вообще на этой фазе нихуя не разбирает).

                                И вот я юзаю этот шаблон:
                                // вот здесь всё заебись, т.к. у вектора есть метод size()
                                std::vector<int> x;
                                size_t s = getSizePlusOne(x);
                                // а вот здесь вывалится ошибка, что у t нету метода size()
                                int p;
                                size_t s = getSizePlusOne(p);
                                Т.е. в текущей версии крестов это самая настоящая утиная типизация (в момент компиляции, конечно же). И в бусте вот это "у t нет метода size()" может вывалиться не на первом уровне, а где-нибудь на глубине в 50 шаблонов. Причём t будет не тем, что ты туда передал, а какой-нибудь неведомой ёбаной хуйнёй из 100500 шаблонов, параметризованных твоим типом. Из-за чего описание ошибки превращается в портянку на пару экранов, в которой хуй поймёшь че от тебя вообще хотят...
                                Ответить
                                • Пардон, но проблема с анализом была же у макросов,как мы к шаблонам пришли?

                                  >Из-за чего описание ошибки превращается в портянку на пару экранов, в которой хуй поймёшь че от тебя вообще хотят...
                                  Как в питоне :) Ну только кода в нем меньше.

                                  Не понял, а чем это отличается от генериков жавы? Что мешает посмотреть в typename?
                                  Ответить
                                  • Ты же сам про шаблоны начал. "Качество анализа практически не зависит от полноты разбора шаблонов, потому что мы их все равно не разбираем?"
                                    Ответить
                                    • Просто я путаю шаблоны и макросы :)

                                      А что сложного в разборе шаблонов-то? Это ведь как генерики в яве?
                                      Ответить
                                      • Генерики в жабе проще. Они же тупо компилятся в функцию/класс с самым общим типом. Ну и немного проверок во время компиляции.

                                        В крестах же шаблон может раскрываться по-разному для разных типов. Т.е. для hui<int> будет генериться один код, а для hui<std::string> можно сделать совсем другой (специализация шаблонов).
                                        Ответить
                                        • Кресто-Шаблоны - это чистый функциональный язык с ленивыми вычислениями, погружённый в кресты. Вот она, глубокая связь хачкелистов с крестолюбами!
                                          Есть даже компилятор, компилирующий ML в шаблоны
                                          http://akabe.github.io/evilml/
                                          Ответить
                                          • > функциональный язык
                                            Вот только гц не завезли...
                                            Ответить
                                        • >шаблон может раскрываться по-разному для разных типов.
                                          Но смысл генериков в том, что бы он раскрывался одинаково для разных типов и при этом проверял типы в статике, а в чем смысл шаблонов плюсов?

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

                                            Генерик - одна обобщённая функция или один класс работающие для некой группы допустимых параметров (поэтому он и generic).

                                            А шаблон это шаблон для генерации пачки функций или классов, по одной для каждого набора параметров.

                                            P.S. Из-за внешнего сходства шаблонов и генериков жабистам и крестовикам довольно сложно въехать в противоположную концепцию...
                                            Ответить
                                            • во ёб :)

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

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

                                                    Вот и пишешь шаблон, который будет юзаться для большинства и специализации под частные случаи. Я х.з. как еще объяснить...

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

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

                                                      И даже если сделать ее в статике - не лучше ли придумать интерфейсы, чтобы этой хуйни не было?
                                                      Ответить
                                                      • Ну вот концепты и будут этими самыми интерфейсами ;)
                                                        Ответить
                                                        • То есть они пошли по пути питона- сначала запилили утиную типизацию, а потом подумали "а как нам все-таки описывать требования к передаваемым объектам" и решили, что без интерфейсов таки никак? Долго шли :)

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

                                                          P.S. http://lurkmore.to/_/118731#mws_i5CVAqm
                                                          Ответить
                                                          • Прибору придётся работать на напряжении сети. Другое дело, что его сердце может не выдержать...
                                                            Ответить
                                                            • А если вытащить вилку - то прибору придется работать без электричества, правда?
                                                              Ответить
                                                              • Ему придётся работать без именно этого интерфейса. Но у него же могут быть аккумуляторы...
                                                                Ответить
              • поиск по группе файлов не помогает?
                Ответить
                • Дольше и без гарантии.Например, вызов метода определенного класса ты так задолбешься искать.
                  Ответить
          • тогда уже лучше clion взять. Оно и дешевле получится
            Ответить
            • > дешевле получится

              С текущей политикой лицензирования - не уверен.

              Да и CLion - тормозная шняга, на самом деле. На приличных проектах он люто, бешено тормозит. У нас мало кто может его использовать, даже с partial checkouts.
              Ответить
              • Допилят. Он же не давно появился.
                Ответить
              • Студия вроде тоже скоростью не блещет. Кто-то тут даже специально ставил 2003, потому что новые версии люто тормозили.

                А что использовать то для крестов?
                Ответить
                • Хз, кресты - говно, все иде для крестов - говно. В основном все хвалят QtCreator, но он почти наверное тоже говно.

                  Я пишу в Emacs на всём подряд. С учётом того, что разработка в осноном на удалённой машине, выбор не особо большой. Да и годы использования вызывают привыкание.
                  Ответить
                  • > С учётом того, что разработка в осноном на удалённой машине
                    Но зачем?
                    Ответить
                    • у нас это называется "секьюрность"
                      чтобы ryska grisar не проебали говнокоды и в интранет ходили ровно одним способом, а не кто как хочет
                      Ответить
                      • Нет

                        Удалённая машина - это сервер без гуя с 64 ядрами и сотнями оперативы. Там стоит специфичная версия линупса, под которую компиляем код.
                        Ответить
                        • Пилишь код прямо на боевом сервере, чтобы не деплоить?
                          Ответить
                        • А ту же самую версию питуха на десктоп накатить? Или все так сложно?
                          Ответить
                          • Есть отважные, кто так делает, но так только больше боли и страданий - под тот линукс пакетов маловато и они все старые. Да и сотни оперативы частенько пригождаются, когда дата-дробилки тестируем.
                            Ответить
                            • А под другими питухами софт даже ради теста не запустить?
                              Ответить
                              • Так всё дебиано-пакетировано, а пакеты, как правило, привязаны к конкретным релизам. Я как-то пытался ставить пакеты из другого релиза, менеджеру пакетов крышу сносит.
                                В общем, на сервере гораздо общепринятей и удобнее. Более того, в большинстве нормальных компаний (фб, гугль) нативный бэкэнд девелопят примерно также.
                                Ответить
                                • А пакеты из исходников ставить вообще никак?

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

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