- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
auto&& rv = elements | std::ranges::views::values | std::ranges::views::transform([](auto&& a) -> auto
{
StatisticsElementMultiple n = std::move(a);
n.nanosec /= n.count;
return n;
});
std::vector<StatisticsElementMultiple> el(std::begin(rv), std::end(rv));
std::ranges::sort(el, [](auto&& a, auto&& b) -> bool {return a.nanosec > b.nanosec; });
for(auto&& [nanosec, name, prefixes, count] : el)
{
printf("%-10d %04X %12s %6d\n", count, prefixes, name.c_str(), nanosec);
}
Follow us!
Хуясе, это что, пайп?
https://en.cppreference.com/w/cpp/language/coroutines
#define co_yield __co_yield
Крестоговнокомпиляторы даже умеют иногда превращать эти рейджи в нормальные циклы, инлайнить transform, разантролливать их и давать оптимальный асм-выхлоп.
https://govnokod.ru/27646#comment669079
Еще раз убеждаюсь, что единственный цисгендерный ЯП это С++.
Писать на скриптоговне допустимо только тем, кто слишком туп для С++ (против природы не попрёшь). Других оправданий нет
Скриптоговно умеет в eval() т.е. возможность в рантайме порождать некий код и выполнение его без лишней питушни. Крестоговно в него не умеет by design, разве что можно насрать кодом крестов в файл, вызывать компилятор для получения dll или so и потом эту говнолибу подгружать и вызывать. Или встраивать какое-то говно типа LLVM и им как-то компилировать из каких-то там блядь байткодов, срать потом инструкциями процессора в исполняемую секцию процесса и вызывать ту хуйню, т.е. это куча геморроя. А еще в крестоговне нет нормальной рефлексии, только какое-то говно ссаное.
Ну и конечно же ма_те_ма_ти_ка показывает легко, что всё что можно сделать евалом, можно было заранее написать как нормальный код. (Или ты там собрался в евал вставлять рандомы и фазы луны заодно с инъекциями?)
Какая-нибудь DSL питушня для внутреннего использования, где во многих местах можно зафигачить выражение непосредственно на языке, на котором это всё построено.
Если нужно передать выражение непосредственно на языке, можно передать колабл, анонимную функцию или лямбзду. За одно не придётся склеивать строки.
С++ толкает вперёд прогресс. Если в крестокомпилятор (шланг) завозят подобные оптимизации, то анскильные скриптомакаки и прочая дrustомразота как обычно их ворует, выпячивает грудь и кичится смотрите #даяжекаксишка.
А оптимизатор для себя написать они оказались не в состоянии.
Потому в явах, ololoLINQ и прочих nodejs лямбды до сих пор дают х5 замедление по сравнению с циклом.
Хотя уже прошло больше десяти лет, как эта фигню туда завезли.
https://leanylabs.com/c3c272e1aeeed21f5a97eda0c3fe8c1a/forEach.svg
Это от создателей "мы оптимизируем код на пхп заменяя двойные кавычки на одинарные"
Ну да. Долго конпелируется, долго оптимизируется.
Лучше же потом в рантайме опечатки и ошибки вылавливать.
Однако иногда есть ситуации, когда нужно динамически поменять алгоритм фильтрации и/или не дублировать код.
И вот тогда эти пайпы в миллион раз лучше и красивше пирдолинга со звёздочками, укокозателями на функции функций и прочей сишной дрочью.
И ассемблерный выхлоп оптимальный в отличие от тормознутых функциональщиков.
всё что угодно, это сахарок над массивом и условым переходом
а теперь расскажи во что ренджи превращает неоптимизирующий компилятор и насколько они получаются тормознутее цикла
а потом расскажи какая разница в продолжительности компиляции между оптимизирующим и неоптимизирующим билдами
плохо это говноренжи которые без оптимизирующего компилятора работают в 100 раз медленнее цикла а с оптимизирующим компилятором компилируются в 100 раз медленнее цикла
https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
Скорость компиляции являет собой даже меньшюю проблему, чем в JS, потому что в С++ всё таки есть инкрементальная компиляция (разумеется, при наличии нормального разбиения кода), а например в webpack ее нет (и компилируется крупное веб приложеньице вебпаком тоже дай боже)
это экзотическое непонимание со стороны человека который не писал на языках с действительно длинными билд таймами, неоптимизированный билд очень важен (и разница в пирформансе, и скорость блида) для удобства и продуктивности разработки
>Скорость компиляции являет собой даже меньшюю проблему, чем в JS, потому что в С++ всё таки есть инкрементальная компиляция (разумеется, при наличии нормального разбиения кода), а например в webpack ее нет (и компилируется крупное веб приложеньице вебпаком тоже дай боже)
это тоже экзотическое непонимание, скорость компиляции это причина по которой с крестов уходят на go или zig а не на раст и по которой с вебпака хуодят на vite или esbuild
То есть ты признаешь, что неоптимизированный билд используют только локально, во время разработки?
Тогда какая разница сколько там вью занимает?
>, скорость компиляции это причина по которой с крестов уходят на go
Это экзотическое непонимание от человека, который не знает, зачем нужны С++.
Уход с С++ на Go это примерно как уход с Си на PHP.
Подскажу: С++ используют ради:
* перформанса
* уже существующего кода
оба требования одинаково не выполняют Go, Bash, и прочие JavaScript
Скорость компиляции JITом -- одна из причин массового перехода программистов на .bat файлы: в них нет никакого JIT, и кстати проблемы "пайпы тормозят по сравнению с фором" в них тоже нету.
[quote]
Our FREE Advanced Library (ntlib.cmd) weighs in at 2782 lines of executable
source script, compressed to 467 lines of runtime.
[/quote]
К сайту в данным момент платный доступ (библиотека полезный функцуий для .cmd файлов продается), так что у вас он не откроется (если вы не скините мне денег на биток) но можно посмотреть предыдущю версию. БЕСПЛАТНО
https://web.archive.org/web/20071026063304/http://ntcmdlib.com/NTCmdLib.asp
Это анскилл. C таким же успехом раньше уходили с крестов на яву.
> уходят на zig
И где эти отважные герои?
gost очень чётко разобрал «zig»
https://govnokod.ru/27159#comment601997
zig хайль
мы построим быстрокомпилирующийся рай.
Вообще история про уход на пхп с с++ по причине времени компиляции это такой лулз примерно из 1991-го года, когда реально люди думали, что скриптоговно хорошо, бо не нужно компилировать