- 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);
}
guest6 19.04.2022 08:54 # 0
guest6 19.04.2022 08:54 # 0
Хуясе, это что, пайп?
Needless 19.04.2022 10:15 # 0
guest6 19.04.2022 10:16 # 0
Soul_re@ver 19.04.2022 10:24 # 0
https://en.cppreference.com/w/cpp/language/coroutines
guest6 19.04.2022 10:34 # 0
Needless 19.04.2022 10:49 # 0
guest6 19.04.2022 10:52 # 0
kcalbCube 23.04.2022 06:59 # 0
#define co_yield __co_yield
kcalbCube 24.04.2022 12:52 # 0
3.14159265 24.05.2022 03:10 # 0
Крестоговнокомпиляторы даже умеют иногда превращать эти рейджи в нормальные циклы, инлайнить transform, разантролливать их и давать оптимальный асм-выхлоп.
https://govnokod.ru/27646#comment669079
guest6 24.05.2022 03:18 # +1
Еще раз убеждаюсь, что единственный цисгендерный ЯП это С++.
Писать на скриптоговне допустимо только тем, кто слишком туп для С++ (против природы не попрёшь). Других оправданий нет
j123123 24.05.2022 04:27 # 0
Скриптоговно умеет в eval() т.е. возможность в рантайме порождать некий код и выполнение его без лишней питушни. Крестоговно в него не умеет by design, разве что можно насрать кодом крестов в файл, вызывать компилятор для получения dll или so и потом эту говнолибу подгружать и вызывать. Или встраивать какое-то говно типа LLVM и им как-то компилировать из каких-то там блядь байткодов, срать потом инструкциями процессора в исполняемую секцию процесса и вызывать ту хуйню, т.е. это куча геморроя. А еще в крестоговне нет нормальной рефлексии, только какое-то говно ссаное.
vistefan 24.05.2022 11:04 # +1
Ну и конечно же ма_те_ма_ти_ка показывает легко, что всё что можно сделать евалом, можно было заранее написать как нормальный код. (Или ты там собрался в евал вставлять рандомы и фазы луны заодно с инъекциями?)
Soul_re@ver 24.05.2022 11:16 # 0
Какая-нибудь DSL питушня для внутреннего использования, где во многих местах можно зафигачить выражение непосредственно на языке, на котором это всё построено.
guest6 24.05.2022 11:29 # 0
vistefan 24.05.2022 12:22 # 0
Если нужно передать выражение непосредственно на языке, можно передать колабл, анонимную функцию или лямбзду. За одно не придётся склеивать строки.
3.14159265 24.05.2022 06:03 # 0
С++ толкает вперёд прогресс. Если в крестокомпилятор (шланг) завозят подобные оптимизации, то анскильные скриптомакаки и прочая дrustомразота как обычно их ворует, выпячивает грудь и кичится смотрите #даяжекаксишка.
А оптимизатор для себя написать они оказались не в состоянии.
Потому в явах, ololoLINQ и прочих nodejs лямбды до сих пор дают х5 замедление по сравнению с циклом.
Хотя уже прошло больше десяти лет, как эта фигню туда завезли.
https://leanylabs.com/c3c272e1aeeed21f5a97eda0c3fe8c1a/forEach.svg
guest6 24.05.2022 10:47 # 0
Это от создателей "мы оптимизируем код на пхп заменяя двойные кавычки на одинарные"
3.14159265 24.05.2022 17:51 # 0
Ну да. Долго конпелируется, долго оптимизируется.
Лучше же потом в рантайме опечатки и ошибки вылавливать.
guest6 24.05.2022 18:07 # +1
j123123 24.05.2022 04:30 # 0
3.14159265 24.05.2022 05:43 # 0
Однако иногда есть ситуации, когда нужно динамически поменять алгоритм фильтрации и/или не дублировать код.
И вот тогда эти пайпы в миллион раз лучше и красивше пирдолинга со звёздочками, укокозателями на функции функций и прочей сишной дрочью.
И ассемблерный выхлоп оптимальный в отличие от тормознутых функциональщиков.
guest6 24.05.2022 10:33 # +2
всё что угодно, это сахарок над массивом и условым переходом
guest6 24.05.2022 08:34 # 0
bootcamp_dropout 24.05.2022 08:35 # 0
а теперь расскажи во что ренджи превращает неоптимизирующий компилятор и насколько они получаются тормознутее цикла
а потом расскажи какая разница в продолжительности компиляции между оптимизирующим и неоптимизирующим билдами
guest6 24.05.2022 10:32 # 0
bootcamp_dropout 24.05.2022 11:23 # 0
плохо это говноренжи которые без оптимизирующего компилятора работают в 100 раз медленнее цикла а с оптимизирующим компилятором компилируются в 100 раз медленнее цикла
https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
guest6 24.05.2022 11:27 # 0
Скорость компиляции являет собой даже меньшюю проблему, чем в JS, потому что в С++ всё таки есть инкрементальная компиляция (разумеется, при наличии нормального разбиения кода), а например в webpack ее нет (и компилируется крупное веб приложеньице вебпаком тоже дай боже)
bootcamp_dropout 24.05.2022 11:36 # 0
это экзотическое непонимание со стороны человека который не писал на языках с действительно длинными билд таймами, неоптимизированный билд очень важен (и разница в пирформансе, и скорость блида) для удобства и продуктивности разработки
>Скорость компиляции являет собой даже меньшюю проблему, чем в JS, потому что в С++ всё таки есть инкрементальная компиляция (разумеется, при наличии нормального разбиения кода), а например в webpack ее нет (и компилируется крупное веб приложеньице вебпаком тоже дай боже)
это тоже экзотическое непонимание, скорость компиляции это причина по которой с крестов уходят на go или zig а не на раст и по которой с вебпака хуодят на vite или esbuild
guest6 24.05.2022 11:50 # 0
То есть ты признаешь, что неоптимизированный билд используют только локально, во время разработки?
Тогда какая разница сколько там вью занимает?
>, скорость компиляции это причина по которой с крестов уходят на go
Это экзотическое непонимание от человека, который не знает, зачем нужны С++.
Уход с С++ на Go это примерно как уход с Си на PHP.
Подскажу: С++ используют ради:
* перформанса
* уже существующего кода
оба требования одинаково не выполняют Go, Bash, и прочие JavaScript
bootcamp_dropout 24.05.2022 11:53 # 0
guest6 24.05.2022 15:58 # +1
kcalbCube 24.05.2022 16:48 # 0
guest6 24.05.2022 17:14 # +1
Скорость компиляции JITом -- одна из причин массового перехода программистов на .bat файлы: в них нет никакого JIT, и кстати проблемы "пайпы тормозят по сравнению с фором" в них тоже нету.
guest6 24.05.2022 17:17 # 0
[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
3.14159265 24.05.2022 17:36 # 0
Это анскилл. C таким же успехом раньше уходили с крестов на яву.
> уходят на zig
И где эти отважные герои?
gost очень чётко разобрал «zig»
https://govnokod.ru/27159#comment601997
guest6 24.05.2022 18:06 # 0
zig хайль
мы построим быстрокомпилирующийся рай.
Вообще история про уход на пхп с с++ по причине времени компиляции это такой лулз примерно из 1991-го года, когда реально люди думали, что скриптоговно хорошо, бо не нужно компилировать
nyTuH_nugop 24.05.2022 19:18 # 0
guest6 19.04.2022 18:27 # 0
kcalbCube 20.04.2022 04:42 # 0
guest6 20.04.2022 04:54 # 0