- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
Type
ONETWO = 1 .. 2;
var I: ONETWO;
begin
I:=1;
I:=I+1;
writeln(I); //2
I:=1+I;
writeln(I); //3
inc(I);
writeln(I); //4
inc(I);
writeln(I); //5
end.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
Type
ONETWO = 1 .. 2;
var I: ONETWO;
begin
I:=1;
I:=I+1;
writeln(I); //2
I:=1+I;
writeln(I); //3
inc(I);
writeln(I); //4
inc(I);
writeln(I); //5
end.
https://ideone.com/mtmPPq
Всё что нужно знать о продвинутой тупизации в «Паскале».
Отребье годами блеяло, что у них там супер-типизация, ошибки ищет компилятор и никаких проблем нет. Но как всегда обделались.
Вообще хуйня полная. Там где я хочу иметь saturation arithmetic — получи wrap-around.
Где я хочу иметь wrap-around — получи runtime error.
https://ideone.com/kkuVbl
Почему succ для енумов бросает ошибку, а inc для subrange нет?
А флага для wrap around для таких типов нет?
На вопрос почему я уже не помню, но там была какая-то хрень с inc из-за которой вся эта защитная кокодогенерация не действовала.
Вот именно что хрень.
Во всех пасцалевских туториалах по енумам в пример приводятся дни недели, или месяцы:
Я делаю succ(Sunday) и получаю блять, то чего ожидал меньше всего: ошибку и краш программы!
https://ideone.com/uVCEcB
Даже дети знают что после Sunday идёт Monday, а не Runtime error.
>function SuccMod(x: TWeekDays): TWeekDays;
А можно написать для всех перечислений? Чтобы городить на каждый енум такое.
Именно из-за подобных мелочей Паскаль производит впечатление сырого недоделанного говнища: кругое таскаем, квадратное катаем.
1. Можно реализовать через RTTI (run-time type info). Однако, RTTI для скалярных типов не генерируется (для пирфоманса), поэтому енум нужно завернуть в класс. К тому же в этом случае проверка будет в рантайме, что слишком анскильно.
2. Типы Variant и array of const в качестве параметра аргумента функции не годятся, потому что они поддерживают либо базовые типы, либо классы, и не поддерживают кастомные енумы.
3. Генерики в данном примере не работают, потому что они слишком обобщённые. Если описать generic <T>, то он будет ожидать в качестве T произвольный тип, а не только перечислимый. Говно в функциях High, Low: для массива она вернёт не массив, а скаляр, т. е. тип результата не всегда совпадает с типом аргумента, поэтому High и Low нельзя использовать в генериках. Функции же Succ и Pred на генериках работают. Как ограничить генерик, чтобы запретить ему принимать массивы, я не знаю. Значит, нам нужен вменяемый заменитель функции High.
Как же реализованы функции High, Low, Succ, Pred в модуле System? Они используют хак, недоступный простым смертным. Костыль, который зовёт на помощь компилятор для определённых функций. Тот же костыль разворачивает вызов Write/Writeln с несколькими аргументами в несколько вызовов Write с одним аргументом. Чтобы добавить свою волшебную функцию, нужно патчить таблицу хаков.
А зачем? У каждого энума своя логика, не для всех зацикливание (да и вообще succ) имеет смысл.
В крестах, к примеру, можно написать эту функцию один раз. И дальше просто помечать нужные енумы соответствующим трейтом.
Если много крестушиться - можно разума лишиться. Если разума лишиться - нечем будет крестушиться.
https://wiki.lazarus.freepascal.org/Enumerated_types
https://wiki.freepascal.org/Subranges
Зачем? Зачем?
А с днями месяца вообще беда: там сброс может происходить после 28, после 29, после 30, после 31 в зависимости от месяца, а иногда и от года. Как решать эту проблему? Вводить типы «дни января», «дни февраля простого года», «дни февраля високосного года»?
А переключатель линии А20 будет, чтобы выбирать между зацикливанием и переполнением?
Какая-та уже компилтушня выходит, если продолжать. Календарь на шаблонах.
Тогда ещё круто было бы, чтобы
при ru локали, зато при en
because every pupil knows that week begins with/on Sunday
>type TWeekDays = (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
Это не круто. Это дублирование кода.
Для локали можно просто задать начальный день недели.
>Ты хочешь, чтобы компилятор Паскаля был в курсе всех концепций реального мира?
Множество концепций реального мира сводятся к одной простой: конец — это новое начало.
А я всего-лишь прошу нормальный wrap around для кастомных типов.
Во-вторых, видимо, по мнению авторов паскаля большее количество людей ожидает при инкременте последнего значения энама исключение.
> во всех туториалах демонстрируют перечислимые типы на примерах дней недели
Насчет всех ты обосрался, в американских туториалах первым мембером был бы зоннтаг.
По сути ничего высокоуровневого в них нет.
Например нигде нет нормальной арифметики, и примитивных типов которые не переполняются.
Почти нигде нестандартных типов, в N бит. Везде надо дрочить clamp и проверять не переполнилось ли очередное арифметическое действие.
А реально высокоуровневые вещи есть в ассемблере, типа комманд SSE
Если нет защиты от переполнения, то Цари ноют, что язык недостаточно высокоуровневый.
Если защита от переполнения есть, то Цари ноют, что пирфоманс на 12,5% ниже, чем в божественной сишке.
Но для неё можно было бы ввести отдельные операторы. Есть же языки программирования, в которых для целочисленного деления и для деления в плавающих питухах разные значки.
Он не unsafe.
uint8_t можно рассматривать как группу из 256 перестановок Галуа
Или modulo arithmetic с основанием 256.
Наоборот пасцалистам можно завезти safe<int>, который кидает в рантайме ошибки, при переполнении.
> safe
В моём примере он назван checked.
z = x =(-100+200)= y;
https://arstechnica.com/tech-policy/2017/06/sorry-maam-you-didnt-win-43m-there-was-a-slot-machine-malfunction/
Imagine, if you would, how absolutely giddy you'd be if you won a $43 million jackpot while playing a casino slot machine. You could burn a lot of bridges with that amount of cash.
Then imagine the opposite feeling you'd get when the casino tells you there was a "malfunction" and you're not getting that jackpot, even though the slot machine lit up and said it was "printing cash ticket $42,949,672.76."
That really happened in August 2016 to Katrina Bookman, who is now suing the Resorts World Casino in Queens County Supreme Court, demanding that she get her payout from the Sphinx slot machine.
This isn't the first time a slot machine has malfunctioned, resulting in a gambler being denied serious cash. An 87-year-old Illinois woman gambling in Iowa had hit a nearly $42 million payout from the Hello Kitty slot machine. But she was denied payment because of a computer glitch.
Iowa's top court ruled in 2015 the slot machine's user-agreement, available on the touchscreen, said the maximum payout was $10,000.
"Any message appearing on the screen indicating the patron would receive a $41 million bonus was a gratuitous promise and the casino's failure to pay it could not be challenged as a breach of contract," the Iowa Court ruled.
After news broke of Bookman's plight, the casino said in a statement that "Machine malfunctions are rare, and we would like to extend our apologies to Ms. Bookman for any inconvenience this may have caused." The New York State Gaming Commission has sided with the Resorts World Casino, ruling the there was "clearly a display malfunction" and that the machine's maximum payout was programmed for $6,500. The slot machine was fixed and operating the following day.
Какое переполнение )))
Какой знаковый int )))
https://www.reddit.com/r/ffxiv/comments/58nc1e/critical_healing_values_and_potions/
Меня всегда интересовало, почему size/count/length во всех известных мне языках возвращает знаковый int? Ну хер там с индексом, я ещё могу понять, но как размер может быть отрицательным?
Почему во всех? Только в анскильных.
В жабе других просто нету. Шарп слизали с жабы.
В божественных сишках и крестах есть size_type.
Member type size_type is an unsigned integral type.
According to the 1999 ISO C standard (C99), size_t is an unsigned integer type of at least 16 bit (see sections 7.17 and 7.18.3).
size_t is an unsigned data type defined by several C/C++ standards, e.g. the C99 ISO/IEC 9899 standard, that is defined in stddef.h.1 It can be further imported by inclusion of stdlib.h as this file internally sub includes stddef.h.
This type is used to represent the size of an object. Library functions that take or return sizes expect them to be of type or have the return type of size_t. Further, the most frequently used compiler-based operator sizeof should evaluate to a constant value that is compatible with size_t.
size_t is a type guaranteed to hold any array index.
Кроме как тяжёлым наследием сижки это никак не объясняется, ну я так и думал, в принципе.
Я окончательно запутался
Наоборот же: в сишке всё хорошо сделали. Типы возвращаемые size беззнаковые.
Кресты это унаследовали.
В остальных же языках — говно.
Например, в обжектив си [NSArray count] возвращает NSUInteger (https://developer.apple.com/documentation/foundation/nsarray/1409982-count?language=objc), а в Свифте ВНЕЗАПНО уже Int (https://developer.apple.com/documentation/foundation/nsarray/1409982-count)
Пиздец консистентность
>в обжектив си [NSArray count] возвращает NSUInteger
Потому что это в первую очередь «си». А в «си» как уже сказано выше: unsigned.
Пиздец, конечно. Странно, что не завезли фабрику компараторов.
Более большие массивы да, только в те лохматые годы, когда писался Foundation, в ходу были 32 и даже 16-битные рахитектуры, так что в 2014-ом никто не заметил подмены
This helps you avoid converting to convert one Int type to another. Apple has modified classes to follow this guideline.
Ненуашо
Sosi fatal pisos: Index out of range
Кстати, в сишке в файлушне позиции в файле знаковые. Это значит, что в число, обозначающее позицию, вставлено однобитовое число со счётчиком ошибок. И функции могут возвращать код козврата, пока они возвращают значение.
А профессионалы упоротые делают вот так:
А вот хак с битовым отрицанием — это пиздец, конечно. Причём, ЧСХ, для посвящённых оно выглядит максимально интуитивно: просто нумерация массива в обратном порядке, [~0] — первый элемент с конца, [~1] — второй элемент с конца, etc. У меня даже иногда возникают порывы вместо разворота массива проходиться по нему таким вот способом, но приходится их давить — не поймут-с :(.
https://bigpicture.ru/wp-content/uploads/2016/03/big_india1.jpg
Так и не нужна эта питушня. Очень мало ситуаций, когда ты упираешься именно в один бит, и расширение числа на этот бит как-то надолго спасёт.
За счёт питух-кода операции над теми и другими интами одинаковые, цари могут написать библиотеку по интерпретации знакушни как беззнакушни.
А нормальные люди не будут себе трахать мозг лишними кастами-хуястами.
Любая криптушня, любая работа с бинарными данными — это всё unsigned. Это далеко не «очень мало», что и подтверждают разработчики «Java», добавившие анскильный compareUnsigned.
видеть неотрицательные числа там, где по определению идёт работа в поле [-2^(N-1); 2^(N-1)-1) — костыльная питушня.
В криптушне и бинушне обычно используются числа [0, 2), а они влезают в переменную.
> сравнения
Операторы сравнения криптушни/бинушни работают, если числа отрицательные. Всё нормально.
А я и не предлагаю все инты заменять на беззнаковые. Там, где используются отрицательные числа, нужно использовать знаковые типы. Там, где отрицательных чисел быть попросту не может, надо использовать беззнаковые.
> В криптушне и бинушне обычно используются числа [0, 2)
Нет. Хэши, различные ГПСЧ в большинстве случаев используют именно [0; 2^N).
> Всё нормально.
А потом ты делаешь x < y и получаешь эпичный багор.
Только потому что в няшной и крестах дрочили на пирфоманс и заботливо разложили грабли, кастуя signed int в unsigned int...
В более безопасном языке можно раскрывать signed < unsigned во что-то в духе signed < 0 || signed < unsigned и всё будет вполне интуитивно.
А что если я переделаю unsigned в signed?
А вот на «< 0» бурчит про «expression is always false», но, в принципе, его понять можно, потому что это действительно с равной вероятностью может быть как перестраховка программиста, так и его же ошибка.
В криптушне и битушне абстракции настолько далеки от реальности, что сила ремаппинга высока и там одинаково подходят как знаковые, так и беззнаковые числа.
Это питушарские анскильные ГПСЧ.
>> Если я использую гаммирование/сдвиг/преестановку битов в криптушне, я использую операции с данными как они есть, а не с числами.
А я говорю о семантике. Если я сдвигаю неотрицательное число влево — я ожидаю получить неотрицательное число, а не какую-то хуйню с минусом.
Это абстрактные математические ГПСЧ, используемые для описания всех достойных алгоритмов.
> Если я сдвигаю неотрицательное число влево
А в криптушне сдвигаются не числа, а биты. Для чисел же либо нужна длинная арифметика, либо отрицательный хвост не мешает, достаточно не использовать отрицашню.
Я в третий раз повторяю: семантика! Чтение, отладка, вывод, сериализация, передача, сохранение.
Использование знаковых питухов для беззнаковых задач — это лютый костыль. Да, он даёт правильные результаты (пока не начнёшь сравнивать через «<»). Да, его можно использовать. Но нахуя, когда есть гораздо более удобный и семантичный инструмент?
Я вот никак не могу понять почему хеш, ГСПЧ или крипто стали вдруг беззнаковой задачей?
Генерирация случайного числа в диапазоне [-128,128) — это что-то противозаконное?
А про крипту, 1024-- правильно говорит, что важны сами биты.
Любой int в крипте считается не числом, но массивом бит.
Генерировать ГПСЧ может что угодно. Важно, что внутри у него — беззнаковые числа из кольца [0; 2^N).
> важны сами биты
Да. И поэтому иметь тридцать один нормальный бит и ещё один, который внезапно интерпретируется совершенно по-другому — ущербный костыль.
> Любой int в крипте считается не числом, но массивом бит.
…до тех пор, пока не понадобится его сравнить или сдвинуть вправо. Это, кстати, хороший детектор костыля: если всё работает почти правильно, проёбываясь только на каких-то «незначительных» мелочах — с большой вероятностью мы имеем перед собой костыль.
И да, я в четвёртый раз повторюсь: семантика. Программы не существуют как обособленные сферические исходные коды в вакууме. Программы кто-то пишет, программы кто-то читает, программы кто-то отлаживает. Программы что-то пишут: в лог, в вывод, в конфиг, программы обмениваются данными по сети. Чем больше в программе элементов, которые означают не то, чем они являются (как знаковый питух, прикидывающийся беззнаковым), тем более она говно.
Реальный пример говна:
Для сдвига в яве с первых версий есть >>>
А зачем в крипте их сравнивать на больше/меньше — ума не приложу.
>Программы что-то пишут: в лог, в вывод, в конфиг, программы обмениваются данными по сети.
Тоже повторюсь: это массив бит. Криптовое говно никто в здравом уме не печатает в десятичных. Их печатают в хексах или побитово.
>The program 'huj.exe' has exited with code 1073741819
Если бы там было 3073741819 стало бы сильно лучше?
Ещё раз: hex или побитовый вывод.
Печатать побитовые массивы в десятичных числах — анскилл и безумие.
Об этом я и говорю: эмулирование беззнаковых чисел знаковыми питухами — костыль, который для нормальной работы требует ещё больше костылей типа этого. Кстати, это до боли напоминает жабаскриптовские и пхпшные «==»/«===».
> А зачем в крипте их сравнивать на больше/меньше — ума не приложу.
А беззнак нужен не только в крипте, это просто удобный реальный пример. Очевидно, если бы сравнение беззнаковых чисел было никому не нужно — никто и не делал бы ущербный compareUnsigned().
Нет. Не больше. На самом деле отказ от беззнаковых всё значительно упростил.
>>> это единственное что долгие годы связывало жабу с беззнаковым миром.
Костыль — это иметь 2 миллиона стандартных типов и кучу ёбнутных правил для неявных и полуявных конвертаций между собой.
>никто и не делал бы ущербный compareUnsigned()
Его сделали аж в 8ой итерации, по принципу: «чего бы ещё впихнуть» . В принципе ни разу не видел, чтобы кто-то им пользовался.
1 > 0. А с восьмой джавы — 2.
> Костыль — это иметь 2 миллиона типов и кучу ёбнутных правил для конвертации между собой.
С тем же успехом можно заявить, что типы вообще не нужны, инта хватит всем. А массив — единственная нужная структура данных.
>>> даже не эмулирование беззнаковых, а больше работа с числом как с массивом бит.
>типы вообще не нужны, инта хватит всем. А массив — единственная нужная структура данных.
А я это и так постоянно говорю :)
К тому же инт — сам по себе массив бит.
Потому инты являются частной формой массива.
>>> И поэтому иметь тридцать один нормальный бит и ещё один, который внезапно интерпретируется совершенно по-другому — ущербный костыль.
> А я это и так постоянно говорю :)
Это не ты, это царескрипт за тебя говорит.
Поскольку в яве хеши и остальное это тупо массивы байт.
А интерпретировать массив битов, как децимал число повторюсь безумие.
> который внезапно интерпретируется совершенно по-другому — ущербный костыль
В жабе фактически всегда было только 2 интерпретации чисел: как знаковое и как массив бит.
В массиве все биты равноправны.
>>> оператор сдвига массива бит.
А для каких-нибудь бигинтов?
> В жабе фактически всегда было только 2 интерпретации чисел: как знаковое и как массив бит.
В жабе есть только одна интерпретация чисел: как знакового питуха. «compareUnskilled», «>>>» — это просто костыли, ничем не отличающиеся от «===».
> saturating<int> (с сатурацией), checked<int> (с исключением), twos_complement<int> (как в джаве) и unsafe<int>
- как можно в одном треде топить за взаимоисключающие параграфы))
Это ГК, привыкай.
А вообще, нет неявных преобразований — нет кучи ёбнутых правил.
Именно!
bormand в http://govnokod.ru/26502#comment533554 написал:
> В общем я за отдельные типы: saturating<int> (с сатурацией), checked<int> (с исключением), twos_complement<int> (как в джаве) и unsafe<int> (как сейчас). Кому какая семантика нужна, пусть ту и юзает.
3.14159265 в http://govnokod.ru/26502#comment533877 написал:
> Костыль — это иметь 2 миллиона стандартных типов и кучу ёбнутных правил для неявных и полуявных конвертаций между собой.
Ну, в общем-то, как и в любом другом обсуждении. Борманд хочет много типов, а ПИ - мало. И в их споре может родиться истина.
Вы таки до сегодняшнего дня ходили только на личный форум, где всех несогласных с Вами модераторы заранее выгоняли лопатным черенком?
Не совсем.
Я говорю: из коробки не стоит лепить много базовых типов. Их должна быть самая малость. Самых необходимых для реализации стандартной либы. И с продуманной системой конверсии туда-сюда.
Однако должен быть удобный конструктор, которым я смогу настрогать себе произвольный тип. Написанное бормандом, я рассматриваю как конструктор.
И да, ходил только на личный форум, потому предъявите документы, прописку, результаты теста на коровавирус и справку о прохождении натализации.
Просто typedef PLAYER_HP saturated<int8>[0,100] — это явно пользовательский тип с шаблонами и питушнёй.
А вот базовых я бы сделал поменьше.
Это же зоопарк ебаный
https://www.cplusplus.com/reference/cstdint/
Вот в сишке нет базового типа: трёхбитный int, но его можно легко сделать через struct.
А в жабе его тоже нет. Но сделать сложнее. Так вот нужно, чтобы нужный тип было просто сделать, но не нужно иметь говно в списке базовых.
Тут нужно пояснить. Не можешь сделать нормальную систему типов — не мучай жопу.
Лучше никак, чем хуёво. В Java сделали никак. И это лучше, чем хуёво в С++.
> saturating<int> (с сатурацией), checked<int> (с исключением), twos_complement<int> (как в джаве) и unsafe<int>
Мне это виделось как принципиально разные типы. И в целом редкоиспользуемые штуки, а не базовые примитивы языка.
Типа BigDecimal в жабе или классов Ratio, Complex.
Интересно сделали с char. Он вроде как символ, поэтому о знаке говорить бессмысленно, что и отразили в стандарте.
Если я использую гаммирование/сдвиг/преестановку битов в криптушне, я использую операции с данными как они есть, а не с числами.
Причём, напомню в java/javascript извечно был особый тип сдвига >>> для unsigned чисел.
>А нормальные люди не будут себе трахать мозг лишними кастами-хуястами.
Поддерживаю.
Опытные крестовики (в т.ч. Роман на ГК) неоднократно сообщали мне что отсутствие питушни с signed/unsigned это благо, а не проблема.
Это раз.
Сплошной кусок памяти в 2 гига — говно.
Это два.
Да и физически он вряд ли он будет последовательным. Из-за фрагментации памяти.
* Такие объемы могут быть полезны в случае виртуальной памяти, или memory mapped files. Но это не тот случай.
Либо уж size_t и index_t (потому что индекс может быть и -1) сделать несовместимыми с int и разрешить только явные касты.
Или ты что-то другое подразумеваешь?
Ну значит нормально.
https://github.com/dotnet/csharplang/blob/master/spec/types.md#integral-types
> For the binary +, -, *, /, %, &, ^, |, ==, !=, >, <, >=, and <= operators, the operands are converted to type T, where T is the first of int, uint, long, and ulong that can fully represent all possible values of both operands. The operation is then performed using the precision of type T, and the type of the result is T (or bool for the relational operators). It is not permitted for one operand to be of type long and the other to be of type ulong with the binary operators.
А вот второй:
Какой багор )))
UInt64 нельзя сравнивать со знаковыми целыми, зато с десималами-флоатами можно:
Ну и конечно же, да:
В Калифорнии запрещено вето харам слизывать с жаб.
Дело в том, что на юго-западе США водится колорадская жаба (Incilius alvarius), околоушные железы которой выделяют мощный галлюциноген, действие которого похоже на ЛСД.
https://ru.wikipedia.org/wiki/Колорадская_жаба
Такие дела.
Length -- Returns length of a string or array.
https://www.freepascal.org/docs-html/rtl/system/sizeint.html
SizeInt is used to describe sizes of structures in FPC using a signed integer.
И эти люди хвастались что у них продвинутая типизация.
Какой позор )))
Так а что мешало оставить сигнатуры для поиска знаковыми, а Length поменять на беззнаковое?
А в целом, свои взгляды на индексацию массивов и строк я уже высказывал здесь:
https://govnokod.ru/25987#comment512968
Возвращаемый тип должен выводиться компилятором и быть [0,length)
Соответственно всякие substring, slice и array[index] должны принимать этот тип [0,length).
Поскольку длина массива/строки фиксирована, типы можно выводить на этапе компиляции и рантайм проверки не нужны.
Может быть, отрицательные значения зарезервировали на случай, когда нужно вернуть ошибку? Хотя это говно, потому что каждый раз придётся проверять неотрицательность результата. Логичнее было бы возвращать ноль и кидать исключения.
В частности, становится тривиальным обратный обход массива циклом с предусловием.
Это как?
Зачем тут знаковость?
for (uint i=size; i--> 0 ;)
Но тут одновременно -- и > - тонкая питушня, спасает только идеоматичность.
>на процессорах без аппаратной сатурации просядет пирфоманс
>кроссплатформенно сделать не получится
ЯВУ — язык высокого уровня.
Пиздец тогда.
>Почему в ЯВУ не стали включать длинную арифметику? Испугались, что кроссплатформенно сделать не получится и на процессорах без аппаратной сатурации просядет пирфоманс?
Поэтому, если бы я проектировал свой язык, я бы разделил эти концепции. Тогда можно вообще не указывать physical layout для типа, и пусть конпелятор сам пердолится с реализацией, даже если ему придётся длинную арифметику заюзать. А можно наоборот - указать несколько physical layout'ов для типа и юзать их в местах где нужен пирфоманс или маппинг...
Так и есть.
>Поэтому, если бы я проектировал свой язык
То я бы начал с базовых понятий алгебры: кольца и поля.
Потом на основании поля я бы ввёл типы с модульной арифметикой [0,256) и дал возможность выбора их поведения.
>за отдельные типы: saturating<int> (с сатурацией), checked<int> (с исключением), twos_complement<int> (как в джаве) и wrapped<int> (c переполнением)
Потом для wrapped<int> я бы ввёл группы подстановок Галуа.
Допустим 1-битный тип может быть [0,1]. А может быть [1,2]
Любой сдвиг в принципе. [123,124]
Или тип с 256 значениями может быть [-128,128), а может быть [0,256)
Соответственно наиболее частоиспользуемые типы были бы явно определены в стандартной либе как диапазон значений с понятной семантикой переполнения.
Но при желании кодер мог бы задать свой тип: typedef ONETWO wrapped<int> [1..2]
>не будет популярен за пределами СНГ, потому что математику изучают только в рашке
Какой Сёма )))
[0,255] — это же закрытый интервал.
Можно сочинить какую-то compile-time перегрузку [a,b] = (a-1,b+1)
Полуоткрытые нельзя будет сделать. Но для дискретных целых не особо нужно.
Это язык зожатия вореций. Все кобенации кода собераются, зожимаются эффективно коэффициенты 1 2 3 вставляются в стандарт. Код на таком языке после перевода с C++ становится короче, чем при переводе на "винрар".
Тред не читай — сразу отвечай.
>я за отдельные типы: saturating<int> (с сатурацией), checked<int> (с исключением), twos_complement<int> (как в джаве) и unsafe<int> (как сейчас). Кому какая семантика нужна, пусть ту и юзает.
Сложность в реализациях компиляторов. Но это фигня, в сравнении с modern C++.
А если какие-то экзотические диапазоны, тогда конвертация вереницы этих типов туда-сюда.
Неявные касты — источник багров.
Явные преобразования — черезчур многословно.
https://ideone.com/hJUQXe
На строчке, где должно вывести 3, падает с ошибкой 201.
Режим $R+ не стали включать по умолчанию из-за сишников, которые ноют, что проверки снижают пирфоманс.
Опять же вопрос, почему для енумов succ — выдаёт ошибку без флажков, а для subrange нужно их включать? Контринтиутивное говно.
suck(suck(pascal))
https://www.freepascal.org/docs-html/rtl/system/ioresult.html
Ха-ха, 201 здесь есть (range error), а 107 нет в принципе.
Он не обязан знать математику.
Но-но! Не гони на аниме!
Кстати, guest8 - не гость.