Ну, возможно и на C# писать, например) Там можно и такое
var prefixes = new[] { "пу", "зе" };
var result =
from person in collection
let lastName = person.LastName.ToLowerInvariant()
where lastName.Length >= 2
&& prefixes.Contains(lastName[..2])
orderby person.FirstName
select person;
Как угодно будет выглядеть, ведь на С++ есть препроцессор и перегрузка операторов)
Так что на С++ можно написать API любой степени читаемости, хоть бы и такой же как в Ruby. Вопрос во времени разработки, поддержки и исправлению ошибок)
Ну, например, я прямо сейчас смотрю на CI, который занимает 2 часа на каждый PR. PVS в нём - это минут 10. Будет занимать 20 - я не расстроюсь, мне уже пофигу :D В моей голове что 100 быстрых детекторов, что 100 "не так чтобы очень быстрых" - одинаковы)
Так вроде в этом и смысл любой защиты? Заставить подстраиваться так долго, чтобы злоумышленник (по крайней мере большая часть из них) - сочли это неразумной тратой времени.
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: Ладно, убедили, через макросы можно сломать чистоту :) Ну штош, по ходу и правда нет чистых функций в С++.
Ну, возможно и на C# писать, например) Там можно и такое
Как угодно будет выглядеть, ведь на С++ есть препроцессор и перегрузка операторов)
Так что на С++ можно написать API любой степени читаемости, хоть бы и такой же как в Ruby. Вопрос во времени разработки, поддержки и исправлению ошибок)
Потому что действует принцип неуловимого Джо? Перефразируя анекдот:
Мне бо-бо на это смотреть) А я на С++ пишу, я знаю что такое боль)
И прямо по ссылке 4 вида связывания :)
Вы забыли "Модульное". А оно самое упоротое, кстати, и доставляет парочку прикольных проблем :)
UPD
Погуглил, кажется пофиксили те проблемы, о которых я думал. Они были в Modules TS ещё)
Ну, например, я прямо сейчас смотрю на CI, который занимает 2 часа на каждый PR. PVS в нём - это минут 10. Будет занимать 20 - я не расстроюсь, мне уже пофигу :D В моей голове что 100 быстрых детекторов, что 100 "не так чтобы очень быстрых" - одинаковы)
Потому что
std::start_lifetime_asреализовали в GCC 16 только этой весной) А Clang до сих пор не завезли. В MSVC вроде тоже только весной добавили.Так вроде в этом и смысл любой защиты? Заставить подстраиваться так долго, чтобы злоумышленник (по крайней мере большая часть из них) - сочли это неразумной тратой времени.
Надо писать в соответствии с требованиями :) Может и не нужны никому 100 быстрых детекторов. Впрочем, если дают развлекаться - только радуюсь за вас)
Я (условно я) пытаюсь написать обработку аудио, а не кольцевой буфер. Зачем мне писать кольцевой буфер?
enumerate : просто существует)
Какое-то странное утверждение) Пока нет требований к производительности, код должен быть понятным) На любом языке) А остальное вообще пофиг.
Иногда включаю Youtube. Там оч удобно голосом видоскики искать. Ну, иногда пользуюсь онлайн кинотеатрами. Всё это в принципе есть и на ТВ приставках.
Впрочем, мне глубоко похрену что у меня дома стоит прослушка. Ибо принцип неуловимого Джо всё ещё действует.
Ну, на cppreference честно написано
Это уточнение вскрывает ещё одну проблему: диалекты ASM :) Целый зоопарк диалектов.
В чем смысл всё это учить и помнить, если есть Си)
Ну, если брать конкретно rand(), то это наследие С, он компилируется где угодно даже на самой распоследней ручке, включая bare metal, и никакие требования к источнику энтропии в стандарте особо не закрепить.
В С++, впрочем, история похожая.
Ну, а на счёт криптографических примитивов всегда - ломается zero cost abstraction) Я знаю что всем наплевать, но комитет часто прикрывается этой хернёй)
С DOOM опять же не совсем корректный пример) Я не знаю как они использовали эти случайные числа, но скорее всего они озаботились о статистических свойствах циферок в кольцевом буфере.
Я говорил о совсем вырожденных случаях, когда нам просто нужно чтобы "изменения были", но мы вообще не заинтересованы в статистических свойствах этих изменений.
Например, учебные задачи или тестирование, когда нам нужно внести некий хаос в систему. Впрочем даже в последнем случае нам нужно понимать параметры этого хаоса)
Блин, реально ведь сложно придумать ситуацию, когда мы не хотим знать источник энтропии для засеивания ГПСЧ и распределение. Возможно только о криптостойскости мы иногда не хотим думать
Для меня "наколеночный случай" - это когда "мне просто надо, чтобы тут циферка иногда менялась, но на саму циферку мне плевать") А там хоть итератор над кольцевым буфером сделать)
Почему-то внешние данные - это не аргументы?
В хаскелле например все функции чисты, включая лямбды. А они контекст захватывают.
Можно все consteval функции рассматривать как замыкания над внешним миром
Про макросы я сноску сделал отдельную, но если не использовать их внутри consteval функции, то она чистая.
Так, стоп. Можно открыть википедию, но в целом, смысл термина "чистая функция" сводится к тому, что при одинаковых аргументах мы получаем одинаковый результат. Доп условие в том, что мы не "меняем внешний мир", но в consteval функции это сделать нельзя.
Про внешние данные ничего не говорится. Я могу использовать сколько угодно "вшешних" данных, до тех пор пока эти данные константны. А они константны, т.к. на этапе компиляции состояние хранить нельзя (ну, можно, но через ОЧЕНЬ грязные хаки с ADL и отложенной инициализацией шаблонов, о которых я рассказывать не буду).
Соответственно сколько consteval функцию не вызывай с одинаковыми аргументами, она всегда вернет одинаковое значение. А следовательно она чистая.
UPD:
Уточнение: "чистая в рамках одной единицы трансляции".
UPD2:
Ладно, убедили, через макросы можно сломать чистоту :) Ну штош, по ходу и правда нет чистых функций в С++.