Кондишенал бряки невероятно медленные. Если вам надо один раз то да удобно, но если в цикле намного полезнее в коде написать иф с условиями и там уже обычную бряку. Мало того далеко не все условия отладчик принимает, я за 10 лет так и не вкурил каким свойствам должно удовлетворять выражение в кондишене. В общем кондишенал бряки сильно переоценены. Чем я действительно пользовался с большим удовольствием так это профайлер. Он сэкономил огромную кучу времени, хотя полностью не заменяет точечное измерение времени, как и любой сэмплинг профайлер.
У меня есть опыт сравнения дебагера из вс кода ллдб и мракософтлвского. Вс код конечно кхм кхм скажем курит в сторонке по сравнению со студией. Например я много дебажил эскуэл кверики. Так получается что скул это довольно большие строки. Казалось бы в чем сложность показать всю строку целиком в дебагере в 2024 году? Оказывается большая сложность. Казалось бы почему, так сложно сделать так чтобы точка остановки срабатывала именно в моем файле, а не во всех с таким же именем файла? А что насчёт дебаг май код онли? В общем студия безусловно впереди планеты всей, но не за счет каких то килер фич в дебагере, а за счёт правильного гуя вокруг дебагера.
с++26 обещает быть бомбой по круче 11. Рефлексия, возможно экзекутеры, возможно контракты, ну и дофига по меньше. Я думаю ВС 28 принесет с собой этот стандарт и в игрострой. Я вот решил завязывать с плюсами ибо бесконечные УБ в коде я могу фиксить, а вот бесконечные споры на ревью с коллегами о том, что здесь уб нет иди кури бамбук - меня уже утомили окончательно. Судя по статье, в игрострое на меня бы смотрели только с улыбкой и не долго. Мне осталась неделя на плюсах и - я свобоодееен, словно птиица в небеесааах. Ну а всем игростроевцем я желаю, чтобы вендоры своевременно обновляли сдк, тулзы не стояли на месте, компиляторы пофиксили все баги, а стл стал быстрым. И самое главное, что бы начальник смотрел на вас с улыбкой пореже.
Опять же, я согласен с вадимр, шэдовинг это вообще любое присваивание (мутация) или повторная инициализации уже существующего в лексическом контексте имени. А если подробней то шэдовинг это 3 шага:
использование существующего объекта по имени в правой части выражения (опционально)
окончание времени жизни объекта у существующего имени (если нет алиасинга/шаред использования)
инициализация нового объекта и связывание его с именем
При этом тип нового объекта может не совпадать с типом старого, а если совпадает то компилятор имеет право это все оптимизировать (в случае без шаринга) и переиспользовать сторэдж от старого объекта или вызывать специально сделанную для этого функцию/оператор присваивания. Ну если пойти ещё дальше то имхо любой мутабельный/инплэйс вызов в ооп стиле это по факту частный случай шэдовинга. В идеале мутабельных функций нет и тогда вызов создаёт изменённую копию объекта и переприсваивает ему старое имя, удаляет старый объект. Но тут можно заметить что тип == сторэдж под старый объект подходит для нового значит можно оптимизировать и вызвать тот самый спец метод предоставленный программистом который сделает инплэс изменение.
К чему это все? Да к тому, что если чисто функциональный язык без мутаций позволяет шэдовинг то можно писать практически так же как если позволяет мутации т.к. нет никакой разницы (кроме производительности).
Когда нибудь когда у меня будет много свободного времени я может быть запилю прототип такого языка, если конечно хайло к тому времени не доделают.
Вангую на этот пример как минимум ворнинг из за неиспользуемой фак внутри цикла. Ворнинг будет аля переменная инициализирована, но нигде не читается/используется, я на элексире не пишу, но ожидал бы даже еррор в таком коде, ну или в нормальном проекте ворнинг эз еррор. Именно об этом и пишет vadimr у вас компилятор по хорошему не должен принимать такой код, а если вы таки исправите код то он обретёт смысл и шэдовинг не будет проблемой вообще. Я полностью согласен с вадимр в том что шэдовинг НЕ является проблемой и даже наоборот помогает особенно когда нужно преобразовать тип переменной. Например было число, а нужна строка или наоборот или где цепочка преобразований подлинее, заводить 100500 переменных отличающихся суффиксом/префиксом с типом это зашквар особенно если промежуточные или изначальные переменные больше не нужны. Без шэдовинга приходится лексический контекст засирать без толку.
Нет ну если вы таким образом написали: водный растров соды имеет слегка повышенный пэаш (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, но и так уже сложно читать.
Кондишенал бряки невероятно медленные. Если вам надо один раз то да удобно, но если в цикле намного полезнее в коде написать иф с условиями и там уже обычную бряку. Мало того далеко не все условия отладчик принимает, я за 10 лет так и не вкурил каким свойствам должно удовлетворять выражение в кондишене. В общем кондишенал бряки сильно переоценены. Чем я действительно пользовался с большим удовольствием так это профайлер. Он сэкономил огромную кучу времени, хотя полностью не заменяет точечное измерение времени, как и любой сэмплинг профайлер.
У меня есть опыт сравнения дебагера из вс кода ллдб и мракософтлвского. Вс код конечно кхм кхм скажем курит в сторонке по сравнению со студией. Например я много дебажил эскуэл кверики. Так получается что скул это довольно большие строки. Казалось бы в чем сложность показать всю строку целиком в дебагере в 2024 году? Оказывается большая сложность. Казалось бы почему, так сложно сделать так чтобы точка остановки срабатывала именно в моем файле, а не во всех с таким же именем файла? А что насчёт дебаг май код онли? В общем студия безусловно впереди планеты всей, но не за счет каких то килер фич в дебагере, а за счёт правильного гуя вокруг дебагера.
с++26 обещает быть бомбой по круче 11. Рефлексия, возможно экзекутеры, возможно контракты, ну и дофига по меньше. Я думаю ВС 28 принесет с собой этот стандарт и в игрострой. Я вот решил завязывать с плюсами ибо бесконечные УБ в коде я могу фиксить, а вот бесконечные споры на ревью с коллегами о том, что здесь уб нет иди кури бамбук - меня уже утомили окончательно. Судя по статье, в игрострое на меня бы смотрели только с улыбкой и не долго. Мне осталась неделя на плюсах и - я свобоодееен, словно птиица в небеесааах. Ну а всем игростроевцем я желаю, чтобы вендоры своевременно обновляли сдк, тулзы не стояли на месте, компиляторы пофиксили все баги, а стл стал быстрым. И самое главное, что бы начальник смотрел на вас с улыбкой пореже.
Опять же, я согласен с вадимр, шэдовинг это вообще любое присваивание (мутация) или повторная инициализации уже существующего в лексическом контексте имени. А если подробней то шэдовинг это 3 шага:
использование существующего объекта по имени в правой части выражения (опционально)
окончание времени жизни объекта у существующего имени (если нет алиасинга/шаред использования)
инициализация нового объекта и связывание его с именем
При этом тип нового объекта может не совпадать с типом старого, а если совпадает то компилятор имеет право это все оптимизировать (в случае без шаринга) и переиспользовать сторэдж от старого объекта или вызывать специально сделанную для этого функцию/оператор присваивания. Ну если пойти ещё дальше то имхо любой мутабельный/инплэйс вызов в ооп стиле это по факту частный случай шэдовинга. В идеале мутабельных функций нет и тогда вызов создаёт изменённую копию объекта и переприсваивает ему старое имя, удаляет старый объект. Но тут можно заметить что тип == сторэдж под старый объект подходит для нового значит можно оптимизировать и вызвать тот самый спец метод предоставленный программистом который сделает инплэс изменение.
К чему это все? Да к тому, что если чисто функциональный язык без мутаций позволяет шэдовинг то можно писать практически так же как если позволяет мутации т.к. нет никакой разницы (кроме производительности).
Когда нибудь когда у меня будет много свободного времени я может быть запилю прототип такого языка, если конечно хайло к тому времени не доделают.
Вангую на этот пример как минимум ворнинг из за неиспользуемой фак внутри цикла. Ворнинг будет аля переменная инициализирована, но нигде не читается/используется, я на элексире не пишу, но ожидал бы даже еррор в таком коде, ну или в нормальном проекте ворнинг эз еррор. Именно об этом и пишет vadimr у вас компилятор по хорошему не должен принимать такой код, а если вы таки исправите код то он обретёт смысл и шэдовинг не будет проблемой вообще. Я полностью согласен с вадимр в том что шэдовинг НЕ является проблемой и даже наоборот помогает особенно когда нужно преобразовать тип переменной. Например было число, а нужна строка или наоборот или где цепочка преобразований подлинее, заводить 100500 переменных отличающихся суффиксом/префиксом с типом это зашквар особенно если промежуточные или изначальные переменные больше не нужны. Без шэдовинга приходится лексический контекст засирать без толку.
Нет ну если вы таким образом написали: водный растров соды имеет слегка повышенный пэаш (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, но и так уже сложно читать.
Очень интересно, а почему вы так думаете и чем пользуйтесь когда вам надо с классами или указателями работать?