- 1
- 2
- 3
#ifndef _USE_MATH_DEFINES
#define M_PI 3.14159265358979323846
#endif-
Си / Говнокод #18694
−11
Нельзя было сразу M_PI проверять?
Запостил:
3_dar,
08 Сентября 2015
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
>> kegdan 14 часов назад # 0
>> Развели тут - пидар, тридар...
3_14dar в http://govnokod.ru/18694#comment297735 написал:
>> 3_14dar 3 часа назад # +1
>> Был пидар, стал тридар?
11 часов разницы, Карл
А ты?
Каждый раз надо в новом проекте прописывать дефины, которые я до сих пор запомнить не могу
_USEMINMAX или USE_MIN_MAX?
В вашей сраной студии нельзя сделать шаблон для новых проектов? Алсо студия для си же говно?
Правда без визуал ассиста или решарпера для крестов у неё довольно убогий редактор - нету рефакторинга, нормальной навигации и т.п.
Ctrl+click (перейти к определению) не работает? Бля, нахуй она нужна?
Там ведь даже код внутри #ifdef серым подсвечивается, если он не будет компилироваться в текущей конфигурации.
вовремя ты потер. Единорог работает под вижуалкой, а анализирует что хошь
Не повлияет этот ехал макрос через макрос на качество статического анализа IDe?
Не совсем. У него подавление ложных сработок именно под вижуалку, её либу и их особенности заточено. Они там сами писали, что дохуя мусора выдаётся на совсем безобидных конструкциях, когда либц разбирали.
Макросы элементарно раскрываются. Трабла в том, во что они раскрываются. После них же остаётся куча мусора типа 1 == 1. И весь этот мусор как раз попадает в выхлоп анализатора. И надо все такие случаи для известных макросов давить. Для макросов от Майкрософта они это сделали. Для гццшных - нет. Так что на качество анализа влияет - больше ложного мусора в результатах.
Суть анализа же не в том, чтобы выбесить программера миллионом нахуй не нужных предупреждений. А чтобы среди них остались, по возможности, только реальные проблемы а не шлак от раскрытия макро и шаблонов.
Ох еб, они там вручную расставляют костыли, где материться на определенные конструкции, а где нет аки мс в винде 3.1 с цивилизацией.
Все что нужно знать о качестве статических анализаторов для C(++)
как это понимать? Качество анализа практически не зависит от полноты разбора шаблонов, потому что мы их все равно не разбираем?
Там шаблон будет уже не с утиной типизацией, а что-то типа параметр N должен удовлетворять концепту "целое число", а параметр T - концепту "объект, который можно скопировать". Ну и соответственно в момент описания шаблона компилятор проверит, что ты не делаешь с параметрами ничего лишнего, что не описано в этих концептах. А в момент подстановки проверит, что в качестве параметров не передали левую хуйню, не подходящую под концепт.
А шаблоны и так уже на уровне AST работают. Просто у них утиная типизация. Вот, к примеру:Когда компилятор читает описание шаблона, он понимает, что T - какой-то тип. И ничего больше о нём не знает. Кроме совсем базовых проверок тут ничего сделать нельзя (а вижуалка, емнип, нарушает стандарт и вообще на этой фазе нихуя не разбирает).
И вот я юзаю этот шаблон:Т.е. в текущей версии крестов это самая настоящая утиная типизация (в момент компиляции, конечно же). И в бусте вот это "у t нет метода size()" может вывалиться не на первом уровне, а где-нибудь на глубине в 50 шаблонов. Причём t будет не тем, что ты туда передал, а какой-нибудь неведомой ёбаной хуйнёй из 100500 шаблонов, параметризованных твоим типом. Из-за чего описание ошибки превращается в портянку на пару экранов, в которой хуй поймёшь че от тебя вообще хотят...
>Из-за чего описание ошибки превращается в портянку на пару экранов, в которой хуй поймёшь че от тебя вообще хотят...
Как в питоне :) Ну только кода в нем меньше.
Не понял, а чем это отличается от генериков жавы? Что мешает посмотреть в typename?
А что сложного в разборе шаблонов-то? Это ведь как генерики в яве?
В крестах же шаблон может раскрываться по-разному для разных типов. Т.е. для hui<int> будет генериться один код, а для hui<std::string> можно сделать совсем другой (специализация шаблонов).
Есть даже компилятор, компилирующий ML в шаблоны
Вот только гц не завезли...
Но смысл генериков в том, что бы он раскрывался одинаково для разных типов и при этом проверял типы в статике, а в чем смысл шаблонов плюсов?
Т.е. там тоже вызываются какие-то методы переданного типа, но компилятор матерится, когда этот тип не может выполнить то, что хочет код с генериками.
Генерик - одна обобщённая функция или один класс работающие для некой группы допустимых параметров (поэтому он и generic).
А шаблон это шаблон для генерации пачки функций или классов, по одной для каждого набора параметров.
P.S. Из-за внешнего сходства шаблонов и генериков жабистам и крестовикам довольно сложно въехать в противоположную концепцию...
Но подожди.
>А шаблон это шаблон для генерации пачки функций или классов, по одной для каждого набора параметров.
По концепции ООП это разве не должно принадлежать к объекту? Или я фигню сморозил?
В жавке это просто решается - сигнатура определяется не только названием, но и списком параметров, т.е. функции с одинаковым именем для разных типов клепаются на ура. А в плюсах для этого запилили костыль в виде шаблонов? И я все равно не понимаю, что мешает в статике проверить, есть ли у подставляемого объекта нужный метод.
В момент инстанциирования шаблона всё прекрасно проверяется. Проблема в том, что ошибка будет в духе "нету метода х у типа у при раскрытии шаблона ... дохрена строк..." И в том, что в момент описания шаблона нельзя узнать, есть ли нужный метод.
Вот и пишешь шаблон, который будет юзаться для большинства и специализации под частные случаи. Я х.з. как еще объяснить...
Проверки шаблонов всегда идут в статике. Но в момент описания шаблона ничего толком не проверить, т.к. параметры неизвестны, а концепты ещё не завезли. Большая часть проверок будет в момент инстанциирования шаблона, когда он уже раскроется под конкретные параметры (это все еще во время компиляции в статике).
Проблема то не в том, что компилятор в статике не видит ошибок. Всё он видит. Только пишет об этом километровые портянки из которых нихуя не понятно...
И даже если сделать ее в статике - не лучше ли придумать интерфейсы, чтобы этой хуйни не было?
Интерфейс - это ведь не только список, но и контракт. Т.е. если вилка влезет в розетку - это еще не гарантирует, что сеть и прибор работают на одном напряжении.
P.S. http://lurkmore.to/_/118731#mws_i5CVAqm
С текущей политикой лицензирования - не уверен.
Да и CLion - тормозная шняга, на самом деле. На приличных проектах он люто, бешено тормозит. У нас мало кто может его использовать, даже с partial checkouts.
А что использовать то для крестов?
Я пишу в Emacs на всём подряд. С учётом того, что разработка в осноном на удалённой машине, выбор не особо большой. Да и годы использования вызывают привыкание.
Но зачем?
чтобы ryska grisar не проебали говнокоды и в интранет ходили ровно одним способом, а не кто как хочет
Удалённая машина - это сервер без гуя с 64 ядрами и сотнями оперативы. Там стоит специфичная версия линупса, под которую компиляем код.
В общем, на сервере гораздо общепринятей и удобнее. Более того, в большинстве нормальных компаний (фб, гугль) нативный бэкэнд девелопят примерно также.
Сколько людей в сумме пилят бекенд для фейсбука? И то, что даже для теста софт нельзя запустить на локальной машине - кагбэ минус.