There are no guarantees as to the quality of the random sequence produced. In the past, some implementations of rand() have had serious shortcomings in the randomness, distribution and period of the sequence produced (in one well-known example, the low-order bit simply alternated between 1 and 0 between calls).
rand() is not recommended for serious random-number generation needs. It is recommended to use C++11's random number generation facilities to replace rand().(since C++11)
Ну, если брать конкретно rand(), то это наследие С, он компилируется где угодно даже на самой распоследней ручке, включая bare metal, и никакие требования к источнику энтропии в стандарте особо не закрепить.
В С++, впрочем, история похожая.
Ну, а на счёт криптографических примитивов всегда - ломается zero cost abstraction) Я знаю что всем наплевать, но комитет часто прикрывается этой хернёй)
С DOOM опять же не совсем корректный пример) Я не знаю как они использовали эти случайные числа, но скорее всего они озаботились о статистических свойствах циферок в кольцевом буфере.
Я говорил о совсем вырожденных случаях, когда нам просто нужно чтобы "изменения были", но мы вообще не заинтересованы в статистических свойствах этих изменений.
Например, учебные задачи или тестирование, когда нам нужно внести некий хаос в систему. Впрочем даже в последнем случае нам нужно понимать параметры этого хаоса)
Блин, реально ведь сложно придумать ситуацию, когда мы не хотим знать источник энтропии для засеивания ГПСЧ и распределение. Возможно только о криптостойскости мы иногда не хотим думать
Для меня "наколеночный случай" - это когда "мне просто надо, чтобы тут циферка иногда менялась, но на саму циферку мне плевать") А там хоть итератор над кольцевым буфером сделать)
Так, стоп. Можно открыть википедию, но в целом, смысл термина "чистая функция" сводится к тому, что при одинаковых аргументах мы получаем одинаковый результат. Доп условие в том, что мы не "меняем внешний мир", но в consteval функции это сделать нельзя.
Про внешние данные ничего не говорится. Я могу использовать сколько угодно "вшешних" данных, до тех пор пока эти данные константны. А они константны, т.к. на этапе компиляции состояние хранить нельзя (ну, можно, но через ОЧЕНЬ грязные хаки с ADL и отложенной инициализацией шаблонов, о которых я рассказывать не буду).
Соответственно сколько consteval функцию не вызывай с одинаковыми аргументами, она всегда вернет одинаковое значение. А следовательно она чистая.
UPD: Уточнение: "чистая в рамках одной единицы трансляции".
UPD2: Ладно, убедили, через макросы можно сломать чистоту :) Ну штош, по ходу и правда нет чистых функций в С++.
Но у asm-а нет никаких плюсов) Вообще никаких) Я даже отброшу мою субъективную неприязнь к внешнему виду ассемблера и что код на нём - это слишпиеся макарошки :)
Вот список очевидных недостатков
1. Каждая команда - это считай что ключевое слово в языке. Многие ли способны запомнить набор команд для x86_64? А сразу для ARM и x86_64? Да ещё и для всей линейки процессоров. Это делает чистый assembler космически сложным языком просто для запоминания.
2. Современные процессоры давно уже все Out-of-Order, а следовательно и инструкции надо упаковывать так, чтобы оно работало с учётом устройства внутрянки каждого отдельного процессора.
3. Использование ассемблера требует нефига нетривиальных познаний в архитектуре ЭВМ. Даже данные правильно выравнивать будет нафиговой такой когнитивной нагрузкой.
Я не говорю, что у ассемблера нет применений. Я сам писал на нём крипту и переписывание "слово в слово" с чистого Си на ассемблер дало прирост в 15% на ровном месте. И в этом ассемблер оч хорош - числодробилки и общение с железом. Но в массе свой он нахрен не нужен) Никому)
Ну, а "настоящий инженер С++" зарабатывает в среднем по больнице сильно больше научного сотрудника в НИИ или там даже инженера на атомной электростанции.
Значит ли это, что всех научных сотрудников и инженеров заменит ИИ?
Я могу наоборот сказать, что раз С++ программисты в среднем дешевле, значит и заменять ИИ их будут в среднем после того, как заменят всех смузихлёбов)
Нет такой вещи как "просто случайное число от 0 до 100". В принципе, нет ничего простого в случайных числах и случайности вообще. Кроме ну совсем "наколеночных" случаев, но там и просто вызов rand() сойдет.
В любом месте, где требуется случайность, неизбежно возникают вопросы о распределении и о скорости/криптостойкости. Если они не возникают, значит вы не знаете что вы делаете и скорее всего допускаете ошибку/уязвимость
Ну где я такое писал? Переписать придется, но эти изменения минимальные. Их легко реализовать, их легко протестировать. Изменения всех конфигов легко автоматизировать.
Если сравнивать сколько придется сделать для IPv6 - это вообще ни о чём.
Ну, обычно лозунг "никакой свободы врагам свободы" применяют в дискуссиях вида "вы тут говорите про свободу слова, а сами нам запрещаете высказать мнение, суть которого запретить высказывать мнение кому-то ещё".
И как бы контраргумент в том, чтобы дать желающим прочувствовать на себе последствия того, к чему они призывают.
А дальше схема очень простая: кого больше, тот и прав) В этом смысле ни левая, ни правая идеологии не отличаются. Побеждает тот, у кого больше власти.
Мой комментарий был лишь про бессмысленность риторики построенной на "никакой свободы врагам свободы", ведь принцип чрезвычайно самосогласован.
Ну, на cppreference честно написано
Это уточнение вскрывает ещё одну проблему: диалекты ASM :) Целый зоопарк диалектов.
В чем смысл всё это учить и помнить, если есть Си)
Ну, если брать конкретно rand(), то это наследие С, он компилируется где угодно даже на самой распоследней ручке, включая bare metal, и никакие требования к источнику энтропии в стандарте особо не закрепить.
В С++, впрочем, история похожая.
Ну, а на счёт криптографических примитивов всегда - ломается zero cost abstraction) Я знаю что всем наплевать, но комитет часто прикрывается этой хернёй)
С DOOM опять же не совсем корректный пример) Я не знаю как они использовали эти случайные числа, но скорее всего они озаботились о статистических свойствах циферок в кольцевом буфере.
Я говорил о совсем вырожденных случаях, когда нам просто нужно чтобы "изменения были", но мы вообще не заинтересованы в статистических свойствах этих изменений.
Например, учебные задачи или тестирование, когда нам нужно внести некий хаос в систему. Впрочем даже в последнем случае нам нужно понимать параметры этого хаоса)
Блин, реально ведь сложно придумать ситуацию, когда мы не хотим знать источник энтропии для засеивания ГПСЧ и распределение. Возможно только о криптостойскости мы иногда не хотим думать
Для меня "наколеночный случай" - это когда "мне просто надо, чтобы тут циферка иногда менялась, но на саму циферку мне плевать") А там хоть итератор над кольцевым буфером сделать)
Почему-то внешние данные - это не аргументы?
В хаскелле например все функции чисты, включая лямбды. А они контекст захватывают.
Можно все consteval функции рассматривать как замыкания над внешним миром
Про макросы я сноску сделал отдельную, но если не использовать их внутри consteval функции, то она чистая.
Так, стоп. Можно открыть википедию, но в целом, смысл термина "чистая функция" сводится к тому, что при одинаковых аргументах мы получаем одинаковый результат. Доп условие в том, что мы не "меняем внешний мир", но в consteval функции это сделать нельзя.
Про внешние данные ничего не говорится. Я могу использовать сколько угодно "вшешних" данных, до тех пор пока эти данные константны. А они константны, т.к. на этапе компиляции состояние хранить нельзя (ну, можно, но через ОЧЕНЬ грязные хаки с ADL и отложенной инициализацией шаблонов, о которых я рассказывать не буду).
Соответственно сколько consteval функцию не вызывай с одинаковыми аргументами, она всегда вернет одинаковое значение. А следовательно она чистая.
UPD:
Уточнение: "чистая в рамках одной единицы трансляции".
UPD2:
Ладно, убедили, через макросы можно сломать чистоту :) Ну штош, по ходу и правда нет чистых функций в С++.
Но у asm-а нет никаких плюсов) Вообще никаких) Я даже отброшу мою субъективную неприязнь к внешнему виду ассемблера и что код на нём - это слишпиеся макарошки :)
Вот список очевидных недостатков
1. Каждая команда - это считай что ключевое слово в языке. Многие ли способны запомнить набор команд для x86_64? А сразу для ARM и x86_64? Да ещё и для всей линейки процессоров. Это делает чистый assembler космически сложным языком просто для запоминания.
2. Современные процессоры давно уже все Out-of-Order, а следовательно и инструкции надо упаковывать так, чтобы оно работало с учётом устройства внутрянки каждого отдельного процессора.
3. Использование ассемблера требует нефига нетривиальных познаний в архитектуре ЭВМ. Даже данные правильно выравнивать будет нафиговой такой когнитивной нагрузкой.
Я не говорю, что у ассемблера нет применений. Я сам писал на нём крипту и переписывание "слово в слово" с чистого Си на ассемблер дало прирост в 15% на ровном месте. И в этом ассемблер оч хорош - числодробилки и общение с железом. Но в массе свой он нахрен не нужен) Никому)
Ну, а "настоящий инженер С++" зарабатывает в среднем по больнице сильно больше научного сотрудника в НИИ или там даже инженера на атомной электростанции.
Значит ли это, что всех научных сотрудников и инженеров заменит ИИ?
Я могу наоборот сказать, что раз С++ программисты в среднем дешевле, значит и заменять ИИ их будут в среднем после того, как заменят всех смузихлёбов)
Я позволю себе не согласиться.
Нет такой вещи как "просто случайное число от 0 до 100". В принципе, нет ничего простого в случайных числах и случайности вообще. Кроме ну совсем "наколеночных" случаев, но там и просто вызов rand() сойдет.
В любом месте, где требуется случайность, неизбежно возникают вопросы о распределении и о скорости/криптостойкости. Если они не возникают, значит вы не знаете что вы делаете и скорее всего допускаете ошибку/уязвимость
Любая consteval функция - в принципе Pure. Программируйтся всё constexpr/consteval/constinit и будет вам Pure.
Ну... почти. Есть способы даже это обойти через дыры в ADL, причем через баги в стандарте языка, а не в компиляторе) Но это уже детали)
Всё что не constexpr - это просто функции с эффектами, но такие и в Haskell могут делать что угодно)
Строго говоря, operator== может всё ещё делать всё что душе угодно)
deduced this?
Уже ЦИПСО шьют и в краже персональных данных) Например вот
https://www.rbc.ru/economics/01/07/2026/6a4551959a794761c07c3b5a
или вот
https://t.me/warfakes/34708
Может быть, но в ноль ты выходить обязан)
Прибыльность? Ну, т.е. конечно прекрасно когда на альтруистических началах проект некоторое время держится, но очевидно это не успех)
Переделывать в плане логики развертывания и настройки. Возможно стоило мне чуть больше мысль развернуть.
Ну где я такое писал? Переписать придется, но эти изменения минимальные. Их легко реализовать, их легко протестировать. Изменения всех конфигов легко автоматизировать.
Если сравнивать сколько придется сделать для IPv6 - это вообще ни о чём.
Ну, обычно лозунг "никакой свободы врагам свободы" применяют в дискуссиях вида "вы тут говорите про свободу слова, а сами нам запрещаете высказать мнение, суть которого запретить высказывать мнение кому-то ещё".
И как бы контраргумент в том, чтобы дать желающим прочувствовать на себе последствия того, к чему они призывают.
А дальше схема очень простая: кого больше, тот и прав) В этом смысле ни левая, ни правая идеологии не отличаются. Побеждает тот, у кого больше власти.
Мой комментарий был лишь про бессмысленность риторики построенной на "никакой свободы врагам свободы", ведь принцип чрезвычайно самосогласован.
Это очень логичный принцип.
Кто-то выступает, что существует признак, при котором надо дискриминировать людей
Нет проблем. Принимаем эту логику.
Объявляем, что люди выступающие против свободы - должны быть дискриминированв
Примпнчем против врагов свободы - правило несвободы
Всё вернулось на круги своя
Так что "никакой свободы врагам свободы" чрезвычайно логичный принцип, мы просто применяем предложение "врагом свободы" на них самих.