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

    +1

    1. 1
    2. 2
    #include <type_traits>
    int main() { return std::is_assignable_v<int, int>; }

    --> 0

    WTF?

    Запостил: Elvenfighter, 17 Апреля 2019

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

    • https://ru.cppreference.com/w/cpp/types/is_assignable

      Всё сложно. Именно поэтому я за «PHP».
      Ответить
    • std::is_assignable<int, int>::value возвращает false, потому что значению типа int нельзя присвоить значение типа int. Ему вообще ничего нельзя присвоить. Например, выражение 1024-- будет некорректным, потому что значения менять нельзя, можно менять только переменные.

      std::is_assignable<int&, int>::value возвращает true, потому что объект, переданный по ссылке, мы можем редактировать (даже если сама ссылка является константой).

      Нам нужно угадать, что курили те, кто руководствовался такой логикой при разработке стандартной библиотеки.
      Ответить
      • показать все, что скрытоvanished
        Ответить
        • Для простых типов и для непосредственного применения это не нужно: программист и так поймёт, можно ли что-то чему-то присвоить (если нельзя, компилятор ругнётся).

          Возможно, это предназначено для макросни и для всякого говна типа вычисления факториала в компайл-тайме на шаблонах.
          Ответить
          • P.S. Возможно, ещё это можно использовать в autotools (autoconf, configure –— вот это всё) и для написания динамических питухов (типа boost::any, boost::variant, QVariant).
            Ответить
        • Для SFINAE и прочих static_assert'ов.
          Ответить
      • struct Foo {};
        static_assert(std::is_assignable_v<Foo, Foo>);

        А как тебе такое, Илон Маск?
        Ответить
        • https://ideone.com/WA6yO4

          Какой багор )))

          Я не крестовик. Объясните мне, анскильному, что тут вообще происходит.

          Допустим, чистых массивов в сишке и в крестах нет, они передаются по ссылке. Но ведь структуры передаются по значению, значит, по идее должно быть, как с интами.
          Ответить
        • Растровый петух обосрался. Какой анскилл )))
          Ответить
      • показать все, что скрытоvanished
        Ответить
    • Блядь, какое же дерьмище эти ваши плюсы. Тривиально-нетривиально присвоить блядь, что вообще за хуйня? Нахуя всё это?
      Ответить
      • А давайте не будем мыслить бинарно, давайте сделаем полутривиальное присвоение нахуй! Типа std::is_halftrivially_assignable. Нахуя? А хуй его знает. Чтоб побольше ебанистики добавить в язык.
        Ответить
        • Возвращать сложность присваивания как число от 0 до 1.
          Ответить
          • в плавучих питухах
            Ответить
            • или вообще в 2-адических числах
              https://en.wikipedia.org/wiki/P-adic_number#Analytic_approach
              Чтоб посложнее. Чтоб побольше всякой хуйни. Крестовики ведь любят всякое бесполезное дерьмо задрачивать
              Ответить
              • https://govnokod.ru/25456#comment464458

                > Они так хорошо изучили C++ только потому, что он сложный. И если ты хочешь выучить что-то действительно новое, твой путь лежит явно не в какую-нибудь Java, которая специально создана быть простой. Тебе нужно искать в области необычных и странных языков, самых странных, и Haskell автоматически окажется среди самых популярных ответов. Человек видит его, понимает: о, это что-то более сложное, чем C++, нужно выучить. Когда я изучал Haskell, со мной было то же самое, и у меня есть знакомые, которые прошли точно по такой же цепочке рассуждений.

                Да, надо побольше сложностей на ровном месте.
                Ответить
                • Ты напоминаешь мне молодых педерастов, которые по неопытности покупают шиповатые фаллосы.
                  Ответить
            • Крестошаблоны не умеют в плавучего петуха же. Я бы предложил сравнивать в рациональных числах:
              std::is_assignable_complexity_less_then<Left, Right, N, M>::value

              True, если сложность меньше N/M
              Ответить
              • > Крестошаблоны не умеют в плавучего петуха же.

                Можно std::ratio заюзать.
                Ответить
                • > Можно 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.

                  Херня какая-то. Так же не всякое рациональное число можно представить. Почему не сделали чтоб числитель и знаменатель были в бигинтах? И вообще, что насчет компилтайм-бигинтов в крестах?
                  Ответить
                  • Надо Борманда спрашивать, он «AES» на шаблонах писал.
                    На первый взгляд будут серьёзные проблемы из-за крайне извращённого представления динамических массивов в компайл-тайме. Если придумать более-менее адекватный способ хранения разрядов с возможностью манипуляции ими в компайл-тайме, то, думаю, остальное будет не так сложно реализовать.
                    Ответить
                  • Пажжи. По определению рациональные числа как раз и есть N/D. То что так не представляется -- иррациональные числа.

                    А ограничения в границях intmax_t вполне себе "good enough". Для всяких bigint нужно динамическое выделение пам'яти. Такого в компайлтайме пока не можно (но над єтим уже работают).
                    Ответить
                    • > Для всяких bigint нужно динамическое выделение пам'яти. Такого в компайлтайме пока не можно (но над єтим уже работают).
                      Variadic templates хватит всем.
                      Ответить
                    • > А ограничения в границях intmax_t вполне себе "good enough".

                      Для символьных вычислений в компилтайме это не "good enough". Да и к тому же на разных платформах/компиляторах intmax_t может быть разным, что делает эти ваши крестокомпилтаймовые рациональные числа зависимыми от архитектуры/компилятора, что вообще-то попахивает маразмом.
                      Ответить
                      • Блять, как же неймётся тебе. Познакомься с клофелинщицей.
                        Ответить
                      • > Для символьных вычислений в компилтайме это не "good enough"

                        Как например?

                        > Да и к тому же на разных платформах/компиляторах intmax_t

                        Когда ты пишешь/портируешь под платформу, то знаешь какой там intmax_t. Больше intmax_t хардварина просто физически не потянет, зачем напрягать булки?
                        Ответить
                        • > Как например?

                          Очевидно чтоб представлять очень маленькие или очень большие рациональные числа. Т.е. 1/1000000000000000000000000000000000000000 в те ограничения не засунешь

                          > Когда ты пишешь/портируешь под платформу, то знаешь какой там intmax_t. Больше intmax_t хардварина просто физически не потянет, зачем напрягать булки?

                          Зачем мне ебать себе мозги какими-то аппаратными ограничениями, если это компилтайм-херня, которой на это по-хорошему вообще должно быть похеру?
                          Ответить
                          • > 1/1000000000000000000000000000000000000000

                            Я скорее спрашивал о реальных применениях (мы же о нетривиальности присваивания говорим?)

                            У тому же, если очень надо, то float/double/long double вполне себе считаются в constexpr. Но аргументами шаблона быть не могут.

                            Меня еще посетила мысль, что битоебским путем можно сделать IEEE 754 на std::uint32_t и std::uint64_t. Ну или даже проще: хранить мантиссу и порядок параметрами как в std::ratio (интересно, может такое уже есть?)
                            Ответить
                            • > Меня еще посетила мысль, что битоебским путем можно сделать IEEE 754 на std::uint32_t и std::uint64_t. Ну или даже проще: хранить мантиссу и порядок параметрами как в std::ratio (интересно, может такое уже есть?)
                              Не проще ли будет прозрачный fixed-point заебенить?
                              Ответить
                            • > Я скорее спрашивал о реальных применениях (мы же о нетривиальности присваивания говорим?)

                              Ну да, 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-ы и еще куча всякой херни, которую мне лень перечислять.

                              Куда ни плюнь - везде все через жопу сделано с кучей тупых ограничений.
                              Ответить
                              • Нет бы гомоиконы!
                                Ответить
                              • На самом деле все эти ограничения вводятся искусственно: просто если бы их не было, «C++» превратился бы в Идеальный Язык, кто-нибудь написал бы на нём Программу Вселенной, после чего наш мир оказался бы уничтожен в новом Большом Взрыве. Комитет спасает от Апокалипсиса!
                                Ответить
                        • > Когда ты пишешь/портируешь под платформу, то знаешь какой там intmax_t. Больше intmax_t хардварина просто физически не потянет, зачем напрягать булки?

                          Да и собственно с какого хера "точность" представления рациональных чисел в компилтайме должна быть зависимой от intmax_t на какой-то там платформе?
                          Ответить
        • Хотя можно даже пойти дальше, чтоб std::is_trivially_assignable возвращал некое значение, которое бы характеризовало то, насколько тривиально что-то во что-то присваивается. Если совсем-совсем тривиально, то 0. Если чуть менее тривиально, то 1. А вот если вернет std::numeric_limits<uint64_t>::max() то вообще очень все НЕТРИВИАЛЬНО
          Ответить
          • Не, надо чтобы возвращало число до платформозависимой константы, получаемой вызовом ко-ко-констэкспр-функции std::trivially_assignable_complexity_upp er_limit<T>(), а подобрана эта константа должна быть так, чтобы операторы сравнения с ней работали быстрее! А нижний предел — совсем тривиально — std::trivially_assignable_complexity_low er_limit<T>()! О, а ещё надо чтобы возвращаемое число нельзя было прямо кастовать в плавучего питуха (но ни в коем случае не запрещать, только UB сделать), вместо этого в заголовочном файле «<integral>» ввести функцию std::calculate_relative_trivially_assign able_complexity<T, minimum>(complexity, maximum, upper_limit, lower_limit), которая будет переводить сложность в плавучих питухов из полуинтервала [minumum, maximum)!
            Ответить
    • Я против присваиваний.
      Ответить

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