Всё это хорошо, но у вас есть предубеждение, будто бы LLM не способна сказать "не знаю" или "это не так" и вообще не имеет никаких предубеждений. В то время как эти вещи зависят от тренировки модели и инструкций. Даже ChatGPT, если ему сказать, что ответить "не знаю" нормально, начинает реже генерировать бред. Почему его сделали таким, какой он есть, это другой вопрос, и неправильно опыт общения с какими-то моделями обобщать на все возможные LLM.
Не все, и только внутри блока unsafe, который в идеале один на каждый случай реализации структуры данных или интеграции с внешним api.
Пока что этот диалог напоминает анекдот про японскую лесопилку: "Ага, если внутри unsafe подсунуть рандомное число в виде указателя, всё рухнет! Пойду дальше писать на Си с UB в каждой третьей строчке"
А может, потому что разработчикам одного проекта предлагают заняться работой над чем-то другим, что само по себе является токсичным поведением. А ещё потому что новый стандарт Си никак не решит проблем языка, не поломав весь старый код, т.е. либо это бесполезная работа, либо написание нового языка. Оба варианта бессмысленны.
Никак, у сырых указателей нет возможности отслеживать валидность, владельцев, алиасинг и прочие свойства, потому они и сидят за unsafe. Задача программиста, использующего unsafe в коде, - предоставить интерфейс без unsafe, соблюдающий гарантии раста.
Если "доработать" язык, то получится новый язык. Итого вместо переключения на новый язык получится работа над новым языком плюс переключение на него - ещё больше работы.
Если я иду в офис, а потом домой, с большой вероятностью по пути я вспотею хоть немного, и мне потребуется душ. В рамках квартиры я вряд ли вспотею, т.к. контролирую температуру, а физической нагрузки практически нет, поэтому душ требуется реже, а дезодорант вообще не нужен.
В Teardown почти всё разрушается. Можно разобрать машину до рамы с колёсами, и кататься. Куча модов с мощным оружием. При этом есть физика окружения, в отличие от вормс.
Если речь об игре, то от результата сравнения может зависеть, есть коллизия между объектами или нет, из чего могут быть очень далеко идущие последствия.
если у него поведение программы зависит от содержимого младшего бита вещественных чисел, то он просто неправильно выбрал разрядность или его алгоритм ошибочен
Зависимость от младшего бита неизбежна, как только в программе появляется ветвление, основанное на сравнении больше-меньше двух чисел.
Всё это хорошо, но у вас есть предубеждение, будто бы LLM не способна сказать "не знаю" или "это не так" и вообще не имеет никаких предубеждений. В то время как эти вещи зависят от тренировки модели и инструкций. Даже ChatGPT, если ему сказать, что ответить "не знаю" нормально, начинает реже генерировать бред. Почему его сделали таким, какой он есть, это другой вопрос, и неправильно опыт общения с какими-то моделями обобщать на все возможные LLM.
Не все, и только внутри блока unsafe, который в идеале один на каждый случай реализации структуры данных или интеграции с внешним api.
Пока что этот диалог напоминает анекдот про японскую лесопилку: "Ага, если внутри unsafe подсунуть рандомное число в виде указателя, всё рухнет! Пойду дальше писать на Си с UB в каждой третьей строчке"
То есть, ответа от вас вообще не получить? Не уверен, что это говорит в вашу пользу
А может, потому что разработчикам одного проекта предлагают заняться работой над чем-то другим, что само по себе является токсичным поведением. А ещё потому что новый стандарт Си никак не решит проблем языка, не поломав весь старый код, т.е. либо это бесполезная работа, либо написание нового языка. Оба варианта бессмысленны.
Никак, у сырых указателей нет возможности отслеживать валидность, владельцев, алиасинг и прочие свойства, потому они и сидят за unsafe. Задача программиста, использующего unsafe в коде, - предоставить интерфейс без unsafe, соблюдающий гарантии раста.
Если "доработать" язык, то получится новый язык. Итого вместо переключения на новый язык получится работа над новым языком плюс переключение на него - ещё больше работы.
Если это задумано как ссылка, то она не работает.
Отчего же нет? Позволит, первый пункт.
Но ведь написать на расте - это и есть "обложить проверками"!
unsafe в расте даёт ровно пять вещей:
Разыменование сырого указателя
Вызов функции, помеченной unsafe
Доступ на чтение/запись мутабельной статической переменной
Реализация трейта с пометкой unsafe
Доступ к полям union
Борроу чекер и остальные гарантии языка остаются на том же уровне. Что же тут не мощного?
При правильно выстроенной границе между кодом на расте и остальным, кода с unsafe будет совсем немного.
Если я иду в офис, а потом домой, с большой вероятностью по пути я вспотею хоть немного, и мне потребуется душ. В рамках квартиры я вряд ли вспотею, т.к. контролирую температуру, а физической нагрузки практически нет, поэтому душ требуется реже, а дезодорант вообще не нужен.
Даже Страуструп не понимает этого, что уж говорить про простых смертных.
Над кодом на расте компилятору проще рассуждать. Отсутствие алиасинга позволяет проводить оптимизации, которые нельзя делать в Си.
Прямо даже интересно стало, в статье даже турбофиша нет, чего вам показалось страшнее кода на цпп?
В Teardown почти всё разрушается. Можно разобрать машину до рамы с колёсами, и кататься. Куча модов с мощным оружием. При этом есть физика окружения, в отличие от вормс.
Если речь об игре, то от результата сравнения может зависеть, есть коллизия между объектами или нет, из чего могут быть очень далеко идущие последствия.
Зависимость от младшего бита неизбежна, как только в программе появляется ветвление, основанное на сравнении больше-меньше двух чисел.
Я так понимаю, туристов принимать никто уже никогда в будущем не рассчитывает?
А за человеком кто проверять будет? Другой человек? Ха-ха-ха, какая нелепая мысль.
Может, дело в доступности фтора в диете?