- 1
- 2
#include <type_traits>
int main() { return std::is_assignable_v<int, int>; }-
C++ / Говнокод #25547
+1
--> 0
WTF?Запостил:
Elvenfighter,
17 Апреля 2019
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Всё сложно. Именно поэтому я за «PHP».
std::is_assignable<int&, int>::value возвращает true, потому что объект, переданный по ссылке, мы можем редактировать (даже если сама ссылка является константой).
Нам нужно угадать, что курили те, кто руководствовался такой логикой при разработке стандартной библиотеки.
Возможно, это предназначено для макросни и для всякого говна типа вычисления факториала в компайл-тайме на шаблонах.
А как тебе такое, Илон Маск?
Какой багор )))
Я не крестовик. Объясните мне, анскильному, что тут вообще происходит.
Допустим, чистых массивов в сишке и в крестах нет, они передаются по ссылке. Но ведь структуры передаются по значению, значит, по идее должно быть, как с интами.
https://en.wikipedia.org/wiki/P-adic_number#Analytic_approach
Чтоб посложнее. Чтоб побольше всякой хуйни. Крестовики ведь любят всякое бесполезное дерьмо задрачивать
> Они так хорошо изучили C++ только потому, что он сложный. И если ты хочешь выучить что-то действительно новое, твой путь лежит явно не в какую-нибудь Java, которая специально создана быть простой. Тебе нужно искать в области необычных и странных языков, самых странных, и Haskell автоматически окажется среди самых популярных ответов. Человек видит его, понимает: о, это что-то более сложное, чем C++, нужно выучить. Когда я изучал Haskell, со мной было то же самое, и у меня есть знакомые, которые прошли точно по такой же цепочке рассуждений.
Да, надо побольше сложностей на ровном месте.
True, если сложность меньше N/M
Можно std::ratio заюзать.
https://en.cppreference.com/w/cpp/numeric/ratio/ratio
> Each instantiation of this template exactly represents any finite rational number as long as its numerator Num and denominator Denom are representable as compile-time constants of type std::intmax_t.
Херня какая-то. Так же не всякое рациональное число можно представить. Почему не сделали чтоб числитель и знаменатель были в бигинтах? И вообще, что насчет компилтайм-бигинтов в крестах?
На первый взгляд будут серьёзные проблемы из-за крайне извращённого представления динамических массивов в компайл-тайме. Если придумать более-менее адекватный способ хранения разрядов с возможностью манипуляции ими в компайл-тайме, то, думаю, остальное будет не так сложно реализовать.
А ограничения в границях intmax_t вполне себе "good enough". Для всяких bigint нужно динамическое выделение пам'яти. Такого в компайлтайме пока не можно (но над єтим уже работают).
Variadic templates хватит всем.
Для символьных вычислений в компилтайме это не "good enough". Да и к тому же на разных платформах/компиляторах intmax_t может быть разным, что делает эти ваши крестокомпилтаймовые рациональные числа зависимыми от архитектуры/компилятора, что вообще-то попахивает маразмом.
Как например?
> Да и к тому же на разных платформах/компиляторах intmax_t
Когда ты пишешь/портируешь под платформу, то знаешь какой там intmax_t. Больше intmax_t хардварина просто физически не потянет, зачем напрягать булки?
Очевидно чтоб представлять очень маленькие или очень большие рациональные числа. Т.е. 1/1000000000000000000000000000000000000000 в те ограничения не засунешь
> Когда ты пишешь/портируешь под платформу, то знаешь какой там intmax_t. Больше intmax_t хардварина просто физически не потянет, зачем напрягать булки?
Зачем мне ебать себе мозги какими-то аппаратными ограничениями, если это компилтайм-херня, которой на это по-хорошему вообще должно быть похеру?
Я скорее спрашивал о реальных применениях (мы же о нетривиальности присваивания говорим?)
У тому же, если очень надо, то float/double/long double вполне себе считаются в constexpr. Но аргументами шаблона быть не могут.
Меня еще посетила мысль, что битоебским путем можно сделать IEEE 754 на std::uint32_t и std::uint64_t. Ну или даже проще: хранить мантиссу и порядок параметрами как в std::ratio (интересно, может такое уже есть?)
Не проще ли будет прозрачный fixed-point заебенить?
Проще. И fixed'ы всяко предсказуемее чем кастрированный ratio.
Ну да, 640 килобайт хватит всем. Почему ты думаешь, что любые реальные применения укладываются в лимит intmax_t для числителя и знаменателя? Да и вообще на кой хер нужен этот лимит, если это КОМПИЛТАЙМ, ему вообще должно быть насрать на свойство платформы, какое ему должно быть дело до того, какой там intmax_t?
> У тому же, если очень надо, то float/double/long double вполне себе считаются в constexpr. Но аргументами шаблона быть не могут.
Ну это вообще типичная для крестомирка ситуация, куда не посмотри - всюду какие-то тупые ограничения и костыли из костылей из костылей чтоб подпирать костыли из костылей из костылей.
float/double/long double считается в компилтайме через constexpr, но аргументами шаблона быть не могут.
constexpr-ами можно нагенерировать в компилтайме инициализацию какого-нибудь std::array https://govnokod.ru/25407 , но для обычного сишного массива[] это не сработает, только накостыливанием через BOOST_PP_REPEAT https://wandbox.org/permlink/Y1gETtfZyP3AvbBk
Через constexpr-ы нельзя как через шаблоны нагенерировать кучу функций с разными сигнатурами, в constexpr не работают всякие malloc, memset-ы и еще куча всякой херни, которую мне лень перечислять.
Куда ни плюнь - везде все через жопу сделано с кучей тупых ограничений.
Да и собственно с какого хера "точность" представления рациональных чисел в компилтайме должна быть зависимой от intmax_t на какой-то там платформе?