Нет ну если вы таким образом написали: водный растров соды имеет слегка повышенный пэаш (8.4), то да принимается, но нужен конечно декодировщик чтобы понять, что вы имели ввиду.
Упрощённые модели это нормально, разумные, но не точные параметры для оценки тоже нормально, то что вы на автомате поделили на 8 тоже не грех, надо просто потом проверять на базовые вещи/на здравый смысл, большего от таких оценок не требуется. У меня претензий нет, просто у меня такой способ сообщать о найденых ошибках.
Разработчики бывают разные, я конечно не электротехник, но судя по калегам программистам считать за ранее всех причастных к проблеме не олухами я бы не стал, особенно менэнеджерские роли, т.к. даже если кто то внутри команды нашелся кто трубил тревогу ему элементарно могли заткнуть рот и так сойдёт, такое бывало не раз и не два.
Я с вами категорически не согласен. У меня электрочайник с боковой ручкой и высоким носиком как у кувшина. Корпус стекло, я один раз замерил сколько воды помещается в заварочный чайник. Взял маркер и поставил метку. Теперь я всегда наливаю воды ровно столько сколько помещается в заварочный чайник. Остаток не превышает 5-10 мл. Мне особенно нравится когда вообще ничего не остаётся. Вылить всю воду из чайника с высоким носиком и боковой ручкой вообще не проблема, все очень эргономично.
Исходя из моего реального опыта я считаю ваш теоретический анализ скорее вредным чем полезным. Чайник для кипечения воды это решенная проблема ничего там оптимизировать уже не надо.
А вот чайник для заваривания - открытая проблема. Самая большая беда это носик, точнее я до сих пор не понимаю как, по внешнему виду, понять без натур испытаний, что чай не будет стекать по носику на стол в процессе начала/окончания наливания в кружку. При том что испытания на холодной воде могут быть невалидны для горячего чая.
У вас основы электротехники вышли из чата. 8 проводов означает 4 цепи == у пары проводов/контактов будет одинаковый ток равный току в цепи. Поэтому ваши 50 ампер надо делить на 4 а не на 8. Получается в идеальном случае 12.5 Ампера. При максимальном разбросе 2 к 1 получается 16 ампер на одном паре и 8 на другой что даёт 2.5 вата на пару рядом расположенных пинов в цепи 16 ампер.
Никто понятия не имеет, что такое Аги, это я к тому, что вы только что попросили редактора/переводчика дать определение за которое можно сразу в нобелевку получить. Все до одной статьи(включая научные и очень формальные) про аги это спекуляции, поэтому непосредственно разработчики ллмок вообще их не читают, а просто идут вперёд, не тратя время на вот это вот всё.
Сколько раз за свою жизнь вы лично видели корректно написанную программу? Я даже не спрашиваю про ее запуск и ничего не спрашиваю про железо на котором она запускалась.
Вы сначало решите вопрос с корректностью программы хотя бы с сосписком оговорок типа ансэйф код не учитываем, ось не учитываем и т.д.
Короче говоря зачем вы нам рассказываете о том что там у них негров линчуют когда у вас спрашивают конкретно про вашу ответственность в вашей зоне ответственности - корректность вашего кода. Вот когда вы докажите, что он у вас корректен вот тогда у вас и появиться право переводить стрелки на других, а пока это не произошло то ...
В общем за свою жизнь я ещё не разу не видел и даже не слышал про существование хотя бы одной корректной программы даже с большим списком оговорок.
Суть статьи в одном обзаце. Процессор или память могут сбоить - факт. Поэтому, ну его нахер писать корректные программы - оч странная логика, на мой вкус.
Смотрите, с++ это ИСО стандарт. Что такое ИСО стандарт? Это пдфка. Все, там ничего другого нет. Реализация стандарта в виде компилятора и библиотеки к комитету вообще никакого прямого отношения не имеет. Да там заседают много людей которые потом все это имплементируют, но это случайность.
Стандарт полон фич которые уже депрекэйтед или вообще удалены. И знаете каких? Тех которые не взлетели, ну например гц, ограничения на эксепции, когда то давно был экспорт шаблонов, да много чего ещё я не могу всего знать. А знаете кто решает нужна фича или нет? Нет, не вы и не я и не тот парень за соседним столом. Это решают имплементоры стандарта. Их по сути 3. Если они скажут комитет принял какую-то херню и решат ее не имплементировать то вообще не важно, что там в той пдфке написано. И так было не раз.
Ваше предложение добавить в стандарт графику противозачаточное. Оно не имеет шансов воплотится в работающий код ни в одной мне известной вселенной. Даже если комитет его примет. Даже если графика по функционалу будет проще консоли. Это не нужно ни одному вендору.
Едем дальше, предъявите список других стандартов ИСО на языки? Я знаю только ещё один Си. Там ситуация с вашей точки зрения должна быть в 10 раз хуже, я конечно не варюсь в этой экосистеме, но ни разу не видел подобных жужаний.
Языки где все то что вы хотите идёт в библиотеке либо управляются единственным вендором либо сразу рождены с этим функционалом. В других языках эта проблема эффективно решается не стандартом/спекой или ещё чем то похожим, а центральным репозиторием библиотек читай экосистемой/комьюнити.
Мне не нужна графика в стандарте вот вообще никакая, мне нужен центральный репозиторий. Нет, мне не нужен стандартизированный способ сборки, мне нужен центральный репозиторий и я буду с удовольствием жрать любой кактус который этот репозиторий будет использовать для сборки. Ворочать нос, ворчать, но жрать и вслух ещё и нахваливать.
Попыток сделать такой репозиторий много, но центральным ни стала ни одна. Почему? я не знаю, но вижу, что задача объективно сложная, финансово затратная и просто (если вообще возможно) не монетизируемая. Чрезвычайно рискованная черная дыра времени, усилий и денег. Мне кажется для с++ окно возможностей создать такой репозиторий уже закрылось. Его никогда не будет. Смиритесь и живите с этим, ну или запилите уже наконец-то сами :)
Нет, а должен? А что это вообще такое? Расскажите подробнее. Скажите, а как я могу использовать сепульки себе во благо ну или на худой конец против вас соседа? Они вкусные? Где на них можно посмотреть?
У меня другие наблюдения. С одной стороны простой код действительно стал безопасней из коробки и поэтому простым девелоперам сосредоточенным на бизнес логике стало легче писать на плюсах. С другой стороны есть такая категория девелоперов которые явно умнее среднего, но не достаточно, они то как раз герои пословицы горе от ума. Поясню, они достаточно умны, чтобы написать нетривиальный системный/библиотечный код который полон УБ, но работает почти всегда правильно. Ума написать такой же, но без УБ уже не хватает. Это часто проблемы в многопоточном программирование, безопасности памяти, исключений.
Такие люди создают код который приносит невероятного масштаба жопу. Починить(с учётом уже всех существующих юз кейсов) очень сложно, переписать на стандартные/надёжные решения очень дорого, т.к. они отличаются архитектурно/по ограничениям.
Так вот последние нововведения в плюсы вообще никак не помогает таким людям писать более безопасным образом. Атомики прекрасный новый неисчерпаемый кладезь УБ. Понять модель памяти с++ не реально, можно только простить. Написать тесты на код с атомиками задача невероятной сложности. Да даже многопоточные тесты это 99,999% это тупо таймеры. Ни одна душенка в комитете даже не задумывается на эту тему - мы вам дали автомат, а технику безопасности сами как нибудь. Шаред поинтеры, до массового использования атомиков были проблемой номер 1, но атомики конечно победили с большим отрывом. Прекрасный дизайн шаред принтеров спустили в унитаз под названием ГЦ для бедных, только они не ГЦ и проблем создали намного больше чем решили. Теперь понять, что когда умирает в продуктовом коде решительно невозможно. Казалось бы в теории я и не должен, но в реальности ещё как должен.
Новое модное течение - рэнджи. Опять же казалось бы такая классная штука, но теперь рэнджи ради рэнджей везде и понять стало сложнее и тормозить стало больше. Ну спасибо чё.
То что делает комитет все нужно и действительно важно, но вы там почему то забываете писать много хороших примеров как пользоваться новыми игрушками, но ещё важнее написать как НЕ надо пользоваться ими. Где вашу мать техника безопасности на новые приблуды?
У вас тачанка УБ в примерах с player_actions. Что с мьютексом, что тем более с атомиками. Ну если с мьютексом там скорее всего просто опечатка и пример легко починить, то вариант с атомиками в принципе неверен. Несмотря на то что "все изменения" в данных будут видны их нельзя менять/читать одновременно из разных потоков. Может вы спутали пример с двойным буффером когда происходит переключения через атомик поинтер между тем в который пишем и тем из которого читаем, тогда бы это имело смысл, но строго для 2 потоков.
А ещё можно поступить точно так же, но проще - совершенно произвольно запретить на код ревью поднимать темы код стиля и сначало мягко объяснить нарушителем запрета, второй раз жёстко высушить и что то там ещё, а третий последний.
И внезапно люди научаются жить без линтеров, читать код в любом стиле и писать так как душе нравится. Оставить можно только совсем базовые принципы именования и то сделать упор, но то как не надо именовать, но не навязывать жёстко как надо.
Консистентнгсть это миф, у вас в коде всегда смесь, ваш код, стандартная библиотека, фрэймворк, и поверх ещё чужие библиотеки и каждый в своем стиле и нужно часто все это в одном месте/функции. И как то все живут и не жужат, а тут видители колега совсем берега потерял в моей песочнице ссыт не по-моему уставу.
Ну можно и так сказать, но есть более общеупотребительное слово, вы сразу поймете о чем речь если типом х и у будет строка. Я просто взял простой и понятный код и переписал на рэнджи. Потом для проверка попросил кита подумать и объяснить что делает код, умный гад, думал долго, но ответил правильно, но что ещё важнее он показал, что моя прямая попытка смапать на рэнджи работает не совсем так как оригинальный код. В оригинале find_first_not_of, что не тоже самое что и в примере выше. Работает правильно если у содержит 1 элемент, но в оригинале у меня стандартный набор элементов для этого алгоритма в качестве дефолта идет. А написать на рэнджах правильно низя т.к. нету там find_first_not_of. Не подвезли даже в с++26. Можно конечно извернуться и написать через find_if_not + contains/any_of или find_first_if + none_of, но и так уже сложно читать.
Так давайте проверим, алгоритмы говорите, читабельные говорите и все такое блабоабла.
auto xxx(auto& x, auto& y){
using namespace std::ranges;
auto begin = find_first_of(x, y, not_equal_to{});
auto end = find_first_of(subrange(begin, x.end()) | views::reverse, y, not_equal_to{}).base();
return subrange{ begin, end };
}
Назвались груздем полезайте в кузовок. Рэнджи ещё более самые супер пупер лучшие алгоритмы, авто везде не просто так, а что бы алгоритм был максимально дженерик и компилятор/рэнджестроители могли показать максимальную оптимизацию под конкретно ваш случай. Там конечно можно ещё концептов на х, у навесить для пущей пидидитости, но это только добавит шума и не облегчит ответ на вопрос. Что делает эта функция одним словом? Я специально заменил нормальные имена на х, у ибо тогда станет очевидно.
Гусары не читерить, ллмы трёх метровой палкой не трогать. В идеале сипипиреф тоже не открывать если вы за алгоритмы должны и так понять.
Вопрос со звёздочкой насколько производителен такой код? Годен для геймдева?
Так хорошо, а что вы ожидали? Точнее все работает в соответствии со спекой https://en.cppreference.com/w/cpp/container/vector/erase Мне реально интересно какие у вас были ожидания от работы этого метода до того как вы разобрались с вопросом? Второй вопрос вызывающий интерес, когда вы разобрались как это работает почему вы решили написать об этом статью?
Мне кажется, несмотря на то, что вы разобрались как работает ирэйз вам все ещё не понятно почему спека на него именно такая (ну просто какие то деды решили, что так им удобней 100500 лет назад), а не так как вы ожидали. Я могу помочь вам разобраться почему спека именно такая, а не как вы ожидали.
К моему счастью, русский действительно не пригодился. Тот же МФТИ из статьи предлагает зачёт/не зачёт ну чтобы удостовериться, что абитуриент вообще понимает русский и может изъясняться на нем. А вот физика пригождается чуть ли не каждый день, но не по работе, а по жизни. Конкретный раздел - электричество, ну то которое совсем базовое - электротехника, закон ома вот это все. Механика изредка - в общем как раз школьный курс.
Все число дробилки которые я кодил или видел вообще не требует динамической аллокации, если точнее, то она конечно нужна т.к. размер стэка ресурс ограниченный. Все ж таки буфера алоциртся в хипе, но 1 раз перед началом расчетов. Поэтому фиолетово сколько у вас там потоков. Я не видел успешных число дробилок которые чё то динамически аллоцируют посреди рассчетов в таких количествах когда нужно думать об аллокаторах.
Динамическая аллокация жизненно необходима в событийных системах, но если нет жёстких требований по лэтенси то и стандартного аллокатора достаточно. А когда лэтенси важно то первым делом аллокации вообще выпиливают и только когда от них нельзя или дорого избавиться начинают думать над аллокатором.
Нет ну если вы таким образом написали: водный растров соды имеет слегка повышенный пэаш (8.4), то да принимается, но нужен конечно декодировщик чтобы понять, что вы имели ввиду.
ПС нейтральный пэаш 7.0
Не отрицая всего остального что вы говорите, но сода не щёлочь, а соль. Щёлочь все же сильно другое хим. вещество.
Умеет с правильными порошками
Упрощённые модели это нормально, разумные, но не точные параметры для оценки тоже нормально, то что вы на автомате поделили на 8 тоже не грех, надо просто потом проверять на базовые вещи/на здравый смысл, большего от таких оценок не требуется. У меня претензий нет, просто у меня такой способ сообщать о найденых ошибках.
Разработчики бывают разные, я конечно не электротехник, но судя по калегам программистам считать за ранее всех причастных к проблеме не олухами я бы не стал, особенно менэнеджерские роли, т.к. даже если кто то внутри команды нашелся кто трубил тревогу ему элементарно могли заткнуть рот и так сойдёт, такое бывало не раз и не два.
Я с вами категорически не согласен. У меня электрочайник с боковой ручкой и высоким носиком как у кувшина. Корпус стекло, я один раз замерил сколько воды помещается в заварочный чайник. Взял маркер и поставил метку. Теперь я всегда наливаю воды ровно столько сколько помещается в заварочный чайник. Остаток не превышает 5-10 мл. Мне особенно нравится когда вообще ничего не остаётся. Вылить всю воду из чайника с высоким носиком и боковой ручкой вообще не проблема, все очень эргономично.
Исходя из моего реального опыта я считаю ваш теоретический анализ скорее вредным чем полезным. Чайник для кипечения воды это решенная проблема ничего там оптимизировать уже не надо.
А вот чайник для заваривания - открытая проблема. Самая большая беда это носик, точнее я до сих пор не понимаю как, по внешнему виду, понять без натур испытаний, что чай не будет стекать по носику на стол в процессе начала/окончания наливания в кружку. При том что испытания на холодной воде могут быть невалидны для горячего чая.
У вас основы электротехники вышли из чата. 8 проводов означает 4 цепи == у пары проводов/контактов будет одинаковый ток равный току в цепи. Поэтому ваши 50 ампер надо делить на 4 а не на 8. Получается в идеальном случае 12.5 Ампера. При максимальном разбросе 2 к 1 получается 16 ампер на одном паре и 8 на другой что даёт 2.5 вата на пару рядом расположенных пинов в цепи 16 ампер.
Никто понятия не имеет, что такое Аги, это я к тому, что вы только что попросили редактора/переводчика дать определение за которое можно сразу в нобелевку получить. Все до одной статьи(включая научные и очень формальные) про аги это спекуляции, поэтому непосредственно разработчики ллмок вообще их не читают, а просто идут вперёд, не тратя время на вот это вот всё.
Сколько раз за свою жизнь вы лично видели корректно написанную программу? Я даже не спрашиваю про ее запуск и ничего не спрашиваю про железо на котором она запускалась.
Вы сначало решите вопрос с корректностью программы хотя бы с сосписком оговорок типа ансэйф код не учитываем, ось не учитываем и т.д.
Короче говоря зачем вы нам рассказываете о том что там у них негров линчуют когда у вас спрашивают конкретно про вашу ответственность в вашей зоне ответственности - корректность вашего кода. Вот когда вы докажите, что он у вас корректен вот тогда у вас и появиться право переводить стрелки на других, а пока это не произошло то ...
В общем за свою жизнь я ещё не разу не видел и даже не слышал про существование хотя бы одной корректной программы даже с большим списком оговорок.
Суть статьи в одном обзаце. Процессор или память могут сбоить - факт. Поэтому, ну его нахер писать корректные программы - оч странная логика, на мой вкус.
Смотрите, с++ это ИСО стандарт. Что такое ИСО стандарт? Это пдфка. Все, там ничего другого нет. Реализация стандарта в виде компилятора и библиотеки к комитету вообще никакого прямого отношения не имеет. Да там заседают много людей которые потом все это имплементируют, но это случайность.
Стандарт полон фич которые уже депрекэйтед или вообще удалены. И знаете каких? Тех которые не взлетели, ну например гц, ограничения на эксепции, когда то давно был экспорт шаблонов, да много чего ещё я не могу всего знать. А знаете кто решает нужна фича или нет? Нет, не вы и не я и не тот парень за соседним столом. Это решают имплементоры стандарта. Их по сути 3. Если они скажут комитет принял какую-то херню и решат ее не имплементировать то вообще не важно, что там в той пдфке написано. И так было не раз.
Ваше предложение добавить в стандарт графику противозачаточное. Оно не имеет шансов воплотится в работающий код ни в одной мне известной вселенной. Даже если комитет его примет. Даже если графика по функционалу будет проще консоли. Это не нужно ни одному вендору.
Едем дальше, предъявите список других стандартов ИСО на языки? Я знаю только ещё один Си. Там ситуация с вашей точки зрения должна быть в 10 раз хуже, я конечно не варюсь в этой экосистеме, но ни разу не видел подобных жужаний.
Языки где все то что вы хотите идёт в библиотеке либо управляются единственным вендором либо сразу рождены с этим функционалом. В других языках эта проблема эффективно решается не стандартом/спекой или ещё чем то похожим, а центральным репозиторием библиотек читай экосистемой/комьюнити.
Мне не нужна графика в стандарте вот вообще никакая, мне нужен центральный репозиторий. Нет, мне не нужен стандартизированный способ сборки, мне нужен центральный репозиторий и я буду с удовольствием жрать любой кактус который этот репозиторий будет использовать для сборки. Ворочать нос, ворчать, но жрать и вслух ещё и нахваливать.
Попыток сделать такой репозиторий много, но центральным ни стала ни одна. Почему? я не знаю, но вижу, что задача объективно сложная, финансово затратная и просто (если вообще возможно) не монетизируемая. Чрезвычайно рискованная черная дыра времени, усилий и денег. Мне кажется для с++ окно возможностей создать такой репозиторий уже закрылось. Его никогда не будет. Смиритесь и живите с этим, ну или запилите уже наконец-то сами :)
А ты знаешь, что сепульки существует?
Нет, а должен? А что это вообще такое? Расскажите подробнее. Скажите, а как я могу использовать сепульки себе во благо ну или на худой конец против
вассоседа? Они вкусные? Где на них можно посмотреть?У меня другие наблюдения. С одной стороны простой код действительно стал безопасней из коробки и поэтому простым девелоперам сосредоточенным на бизнес логике стало легче писать на плюсах. С другой стороны есть такая категория девелоперов которые явно умнее среднего, но не достаточно, они то как раз герои пословицы горе от ума. Поясню, они достаточно умны, чтобы написать нетривиальный системный/библиотечный код который полон УБ, но работает почти всегда правильно. Ума написать такой же, но без УБ уже не хватает. Это часто проблемы в многопоточном программирование, безопасности памяти, исключений.
Такие люди создают код который приносит невероятного масштаба жопу. Починить(с учётом уже всех существующих юз кейсов) очень сложно, переписать на стандартные/надёжные решения очень дорого, т.к. они отличаются архитектурно/по ограничениям.
Так вот последние нововведения в плюсы вообще никак не помогает таким людям писать более безопасным образом. Атомики прекрасный новый неисчерпаемый кладезь УБ. Понять модель памяти с++ не реально, можно только простить. Написать тесты на код с атомиками задача невероятной сложности. Да даже многопоточные тесты это 99,999% это тупо таймеры. Ни одна душенка в комитете даже не задумывается на эту тему - мы вам дали автомат, а технику безопасности сами как нибудь. Шаред поинтеры, до массового использования атомиков были проблемой номер 1, но атомики конечно победили с большим отрывом. Прекрасный дизайн шаред принтеров спустили в унитаз под названием ГЦ для бедных, только они не ГЦ и проблем создали намного больше чем решили. Теперь понять, что когда умирает в продуктовом коде решительно невозможно. Казалось бы в теории я и не должен, но в реальности ещё как должен.
Новое модное течение - рэнджи. Опять же казалось бы такая классная штука, но теперь рэнджи ради рэнджей везде и понять стало сложнее и тормозить стало больше. Ну спасибо чё.
То что делает комитет все нужно и действительно важно, но вы там почему то забываете писать много хороших примеров как пользоваться новыми игрушками, но ещё важнее написать как НЕ надо пользоваться ими. Где вашу мать техника безопасности на новые приблуды?
Ничего не понятно про этот релокэйт, но очень интересно.
Вопрос, это вообще ок или это ещё один способ написать УБ? Если ок, то будет ли вызван деструктор для х? А что насчёт у был не пустым?
У вас
тачанкаУБ в примерах с player_actions. Что с мьютексом, что тем более с атомиками. Ну если с мьютексом там скорее всего просто опечатка и пример легко починить, то вариант с атомиками в принципе неверен. Несмотря на то что "все изменения" в данных будут видны их нельзя менять/читать одновременно из разных потоков. Может вы спутали пример с двойным буффером когда происходит переключения через атомик поинтер между тем в который пишем и тем из которого читаем, тогда бы это имело смысл, но строго для 2 потоков.А ещё можно поступить точно так же, но проще - совершенно произвольно запретить на код ревью поднимать темы код стиля и сначало мягко объяснить нарушителем запрета, второй раз жёстко высушить и что то там ещё, а третий последний.
И внезапно люди научаются жить без линтеров, читать код в любом стиле и писать так как душе нравится. Оставить можно только совсем базовые принципы именования и то сделать упор, но то как не надо именовать, но не навязывать жёстко как надо.
Консистентнгсть это миф, у вас в коде всегда смесь, ваш код, стандартная библиотека, фрэймворк, и поверх ещё чужие библиотеки и каждый в своем стиле и нужно часто все это в одном месте/функции. И как то все живут и не жужат, а тут видители колега совсем берега потерял в моей песочнице ссыт не по-моему уставу.
Ну можно и так сказать, но есть более общеупотребительное слово, вы сразу поймете о чем речь если типом х и у будет строка. Я просто взял простой и понятный код и переписал на рэнджи. Потом для проверка попросил кита подумать и объяснить что делает код, умный гад, думал долго, но ответил правильно, но что ещё важнее он показал, что моя прямая попытка смапать на рэнджи работает не совсем так как оригинальный код. В оригинале find_first_not_of, что не тоже самое что и в примере выше. Работает правильно если у содержит 1 элемент, но в оригинале у меня стандартный набор элементов для этого алгоритма в качестве дефолта идет. А написать на рэнджах правильно низя т.к. нету там find_first_not_of. Не подвезли даже в с++26. Можно конечно извернуться и написать через find_if_not + contains/any_of или find_first_if + none_of, но и так уже сложно читать.
Очень интересно, а почему вы так думаете и чем пользуйтесь когда вам надо с классами или указателями работать?
Так давайте проверим, алгоритмы говорите, читабельные говорите и все такое блабоабла.
Назвались груздем полезайте в кузовок. Рэнджи ещё более самые супер пупер лучшие алгоритмы, авто везде не просто так, а что бы алгоритм был максимально дженерик и компилятор/рэнджестроители могли показать максимальную оптимизацию под конкретно ваш случай. Там конечно можно ещё концептов на х, у навесить для пущей пидидитости, но это только добавит шума и не облегчит ответ на вопрос. Что делает эта функция одним словом? Я специально заменил нормальные имена на х, у ибо тогда станет очевидно.
Гусары не читерить, ллмы трёх метровой палкой не трогать. В идеале сипипиреф тоже не открывать если вы за алгоритмы должны и так понять.
Вопрос со звёздочкой насколько производителен такой код? Годен для геймдева?
Так хорошо, а что вы ожидали? Точнее все работает в соответствии со спекой https://en.cppreference.com/w/cpp/container/vector/erase Мне реально интересно какие у вас были ожидания от работы этого метода до того как вы разобрались с вопросом? Второй вопрос вызывающий интерес, когда вы разобрались как это работает почему вы решили написать об этом статью?
Мне кажется, несмотря на то, что вы разобрались как работает ирэйз вам все ещё не понятно почему спека на него именно такая (ну просто какие то деды решили, что так им удобней 100500 лет назад), а не так как вы ожидали. Я могу помочь вам разобраться почему спека именно такая, а не как вы ожидали.
К моему счастью, русский действительно не пригодился. Тот же МФТИ из статьи предлагает зачёт/не зачёт ну чтобы удостовериться, что абитуриент вообще понимает русский и может изъясняться на нем. А вот физика пригождается чуть ли не каждый день, но не по работе, а по жизни. Конкретный раздел - электричество, ну то которое совсем базовое - электротехника, закон ома вот это все. Механика изредка - в общем как раз школьный курс.
Все число дробилки которые я кодил или видел вообще не требует динамической аллокации, если точнее, то она конечно нужна т.к. размер стэка ресурс ограниченный. Все ж таки буфера алоциртся в хипе, но 1 раз перед началом расчетов. Поэтому фиолетово сколько у вас там потоков. Я не видел успешных число дробилок которые чё то динамически аллоцируют посреди рассчетов в таких количествах когда нужно думать об аллокаторах.
Динамическая аллокация жизненно необходима в событийных системах, но если нет жёстких требований по лэтенси то и стандартного аллокатора достаточно. А когда лэтенси важно то первым делом аллокации вообще выпиливают и только когда от них нельзя или дорого избавиться начинают думать над аллокатором.