- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
#include <chrono>
#include "SomeShittyLib.h"
// ...
//Fuck you.
#undef min
auto min_seconds = std::chrono::seconds::min();
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+4
#include <chrono>
#include "SomeShittyLib.h"
// ...
//Fuck you.
#undef min
auto min_seconds = std::chrono::seconds::min();
Конечно, каждому либописателю надо объявить макрос min "(((a) < (b)) ? (a) : (b))", ведь вызов функции - это пиздец какие накладные расходы!
Первый вариант оптимизирован по размеру
Второй -- по скорости
В общем, нахуй и в пизду такие предложения. Особенно для крестов, где потребность в макросах намного ниже, чем в няшной.
тем что полиморфен?
З.Ы. А за именование макроса не капсом надо вешать, потрошить и четвертовать. Привет чувакам из майкрософт, которые понадефайнили всякой хуйни в духе min, max и interface.
С недавнего Qt World Summit 2017: Текстовое представление: Герб Саттер предложил заменить на Любопытно будет почитать твиттерное нытьё разрабов вижуальника, если это примут.
Да заебали уже просто добавлять в язык очередной частный случай, честное слово...
> замороченную метушню
В кои-то веки придумали единственную годную фичу за все последние годы - компайл-тайм рефлексию и генерецию кода. Но эту фичу не примут, не по крестоблядски это - крестухам будет обидно, что половина их метушения с шаблонами, макросами и внешними генераторами станет нинужной, да и новые фичи в язык каждый год добавлять уже не получится.
Что плохого? От того что в язык добавят обобщенную метамокропиську, интерфейсы сами не появятся - все равно их нужно будет добавлять в язык. Свои интерфейсы в каждом проекте - это плохо. Как бы не был плох го, но то что там у всех все одинаково и все гоферы понимают код друг друга - это сильная сторона языка.
Я тут где-то уже говорил, что язык для создания диалектов != язык программирования. Программисту нужен ЯП, а не конструктор сделай сам.
не нужен конструктор? а как же DSL?
Некоторые япы (груви, например) прямо таки позиционирует себя как ЯП для DSL
Ненужно. Делать мне нечего, как в каждом хеловорлде с новым дслем разбираться.
Graddle, puppet, Vagrant итд же
много их
Блин, одному программисту нужны инструменты/библиотеки, чтобы писать утилиты, второму нужны выразительные средства языка, чтобы писать те самые инструменты и библиотеки. По факту метаклассы нужны чтобы многие фичи реализовывать и протаскивать в стандарт за пару месяцев в виде библиотек, а не 5 лет в виде language core feature. А первой категории кодеров будет глубоко похуй, interface это метакласс, расширение компилятора, макрос ебанософта или ключевое слово языка; лишь бы работало
Можно, конечно, обойтись и без него. Но это зачастую куда большие трудозатраты совершенно без профита. Платят-то за результат, а не за строки
Во-первых, сомнительное утверждение. Во-вторых, это не все, что нужно от кода - есть еще простота и поддерживаемость. В-третьих, я могу представить, почему метухам приятно думать, что они занимаются чем-то неебаться сложным и полезным, но это не более чем самообман.
Для хорошего метушения надо быть метаметапрограммистом. А у нас больше воюют с реализацией. Не поняли, наследовать int от real, или наоборот - создали общего предка "Number"; не смогли реализовать оптимально математическую запись - ввели указатели и возню с памятью; не смогли в неявную асинхронность - ввели коллбеки, async/await. И получается, что код, решающий вопросы доставки угля, не про поезда и грузовики, а про абстрактные фабрики фабрик, генераторы итераторов и темплейт визиторы.
Потому-то метушня с абстракциями частенько вредят, выделяя шизофренически точно какие-то побочные общие признаки кода.
Но без этого приходится как кэп писать циклы с i от 0 до 10 и дублировать код.
... то не будет ни mpl, ни констекспров, ни статик ифов, ни метакласов, ни даже кривого std::variant (вместо него нормальный синтаксис, встроенный в язык), а крестобляди будут уныло писать классы и функции, и дергать письку на свою илитность уже не получится...
Ну уныло же. Натягивать реальный мир на манямирок классов и функций - тоже не дело. Они не везде удачно описывают суть.
https://msdn.microsoft.com/en-us/library/ms676882(v=vs.85).aspx
7 уровней вложенности складывались в два. Или, из недавнего: в одном проекте простой шаблон:
избавил меня от кучи жонглирования с _mm_alloc/_mm_free/unsafe cast. std::complex<float32x4> и вся комплексная арифметика определена для sse3.
Ко всему надо подходить с умом. В противном случае так и будешь кукарекать о том, что вокруг одни метухи
Костылики. Пример полезной удобной абстракции, сильно облегчающей жизнь, реализованной метушками, но появившейся из-за того, что жизнь когда-то была начата неверно.
Кто не верит - ответьте на вопрос: Зачем мне смартпоинтер в реальной жизни? Если контейнер ещё как-то пригодится в математике, то смартпоинтер скорее всего не появляется ни в одной реальной задаче, а является примесной сущностью программирования, порождённою ограничениями модели.
И что оказывается? Что же пошло не так? Всё пошло не так.
Хотели выразительный язык, чтоб говорить с компьютером как можно более естественным образом, а получили феню и школоло-мемасики. Или какие-то абстрактные абстракции, или модные словечки и частные случаи навпихуивали. Чтоб не выстрелить себе в ногу, надо читать книги на 1200 страниц. Чтобы объяснить компьютеру программу, надо писать не на псевдоанглийском, а переписать её на английский язык курильщика канцелярита, пропустить понятия реальной жизни через призму парадигмы, несоответствия прикрыть фиговым листком.
В одной комнате сидели чуваки, и писали на go.
В другой комнате сидели чуваки, и писали на питоне.
Первые сорвали сроки, а вторые нет.
Отсюда он делает логичный вывод что go -- говно, а питон нет.
Как будто только мс грешен.
один фиг Гвидо в этом никто не переплюнет. #define hypot _hypot в python.h
http://en.cppreference.com/w/c/numeric/tgmath
Еще есть всякие offsetof, которые все всю жизнь реализовывали через жмакрос с формальным UB
Блин, а как это вообще запиливали до С11?
З.Ы. Кому вообще понадобилась вся эта type-generic математика в системном языке? Вендоры сишных конпеляторов хотели перетянуть себе часть юзеров с фортрана?
Any function declared in a header may be additionally implemented as a function-like macro defined in the header, so if a library function is declared explicitly when its header is included, one of the techniques shown below can be used to ensure the declaration is not affected by such a macro.
В общем, стандарт разрешает дефайнить любую из стандартных функций (то ли чтобы оставить лазейку для оптимизаций, то ли ради совместимости с существовавшими на тот момент реализациями), если поведение от этого не меняется (в т.ч. можно передавать в такой макрос сложные выражения, брать адрес, андефать этот говномакрос к хуям и т.п.).
А требование нашлось пока только для ассёрта.
у макроса?
потому что если у тебя макрос определен как обычное выражение то я не оч понимаю как у него взять адрес
cos взяли в скобки, чтобы макрос не раскрылся.
Ну вот, а Борманд что-то разнервничался из-за макросов. Берём всё в скобки - и ничего не раскрывается.
А что делать с макросами без параметров?
К сожалению в си нет уобщепринятого кодстайла (как в жабе или сисярп), так что Борманд не прав.
Разные либы имеют разные подходы
А у яблок и вовсе макросы косят под функции
например XCTAssert это мокрос
Да пошли они нахуй со своим макроговном, засирающим глобальный неймспейс!
У себя в реализации пусть хоть if'ы редефайнят, лишь бы из публичных хедеров не торчало.
там нету неймспейса в крестовом понимании
В формальном крестовом понимании, конечно, нету. А в более общем - есть и не один. В няшной же тайпдефы/переменные и структуры живут в разных "неймспейсах". Плюс более приоритетный "неймспейс" препроцессора.
И вот если имя моей функции или переменной, пересечётся с чем-то, что торчит из хедера какой-то другой либы, то я получу внятную ошибку. А если с макросом - то кровь-кишки, в худшем случае это даже скомпилится но будет делать что-то совершенно левое.
Двух букв хватит всем!!
А в няшной каждый дрочит, как он хочет
у кого pthread_, у кого Nt.
ладно. А у тебя нет IDE которая мокрос и функцию по разному подсвечивает?
> подсвечивает
Ты предлагаешь глазками весь код разглядывать после того как заинклудил что-нибудь? Тем более IDE подсвечивают только для текущего таргета, а не для всех потенциально возможных.
Про таргет -- ок
Согласен
Не увидит, да и не должна - они же в разных "неймспейсах" и всякие #define cos(x) cos(x) вполне допустимы.
Она, конечно, подсветит кейс когда макрос раскрывается в какую-то хуйню, которая не сможет скомпилится... Но мы же о случае, когда даже конпелятор не заметил подвоха.
IDE в любом случае знает и твои макросы и твои функции (Если конечно ты не генеришь функции через макросы) потому что у IDE есть парсер и лексер, и комплишен же как-то раблтает
Вот эта хуйня скомпилится в Foo::CreateFileW. Успешно скомпилится, и даже будет работать (разве что CreateFile будет подсвечен немного не тем цветом, как обычно). Но слинковаться с файлом, где windows.h не инклудили, увы, не удастся.
Помню как я когда-то через макрос перегружал функции malloc calloc и free, чтоб посчитать количество этих вызовов и убедиться что вся выделенная память всегда освободжается