Компилятор в момент компиляции знает как представлены в на целевой машине знаковые числа — дополнительными кодами или как-то по другому.
Unspecified behavior должен приводить к одному из валидных результатов, которые должен быть детерминистичен для конкретной программы, но это не значит, что сложение должно выполняться определенным образом
> Если вы заставляете все выражения иметь определенное поведение, вы ограничиваете возможности компилятора по оптимизации. Например, некоторые алгебраические упрощения для целых чисел недопустимы, если вы требуете, чтобы переполнение знаковых целых арифметических выражений было четко определено.
Вот это например. Unspecified означает, что переполнение знаковых целых может быть 0, 1, -2 миллиарда, 5, и вообще какое угодно число. Ну и делайте свои алгебраические упрощения.
UB означает, что переполнение знаковых целых может быть «отформатировать жесткий диск» или «запустить ядерные ракеты». Не подскажете, зачем вам это для алгебраических упрощений?
Ну например в Rust и Fortran есть гарантия non-aliasing — компилятор имеет право считать, что ничего не поменяет значение переменной, кроме записи в эту самую переменную. Это значительно проще, а также дает больший выигрыш по оптимизации.
А можно эту функцию отключить как-нибудь? С первым ребенком Алиса оказывала большое дисциплинирующее влияние на дикцию. Типа «давай старайся, говори разборчиво, иначе Алиса сказку не включит».
Тут есть ещё один момент. Если ваши финансовые отношения с заказчиком строятся по модели контрактной разработки fix price, заказчик в принципе не может получить качественный продукт и качественный код.
Если кому интересно, я хотел комиксы для этой статьи сделать https://habr.com/ru/articles/825880/ но не дождался буквально пары дней. Теперь придется делать :-))
А если вы продаете заказчику каждую задачу в отдельности (представляю такие контракты, это обычно типа поддержка какой-то системы и идёт поток мелких доработок), то вам каждую задачу надо оценивать. Соответственно и анализировать.
Все верно. В каком случае проще совершить глобальную ошибку в архитектуре? Если мы проверяем и обсуждаем ее заранее, до написания кода, или все изменения в архитектуре окажутся видны другим членам команды только на код ревью?
А что же такое закрашено у вас там в платформах:-))?
Ядро это и есть на 90% драйверы.
Собственно, сейчас конфликт и заключался в том, что проект Rust for Linux пытался запихать обвязку для написания файловой системы на Rust
Это псевдонимность
> Если же переполнение unspecified, то замену делать нельзя.
Вот этого я не понимаю.
Если op2 во всех случаях возвращает C, которое является валидным интом, но который иногда не равен результату op1, то это подойдет.
Компилятор в момент компиляции знает как представлены в на целевой машине знаковые числа — дополнительными кодами или как-то по другому.
Unspecified behavior должен приводить к одному из валидных результатов, которые должен быть детерминистичен для конкретной программы, но это не значит, что сложение должно выполняться определенным образом
> Если вы заставляете все выражения иметь определенное поведение, вы ограничиваете возможности компилятора по оптимизации. Например, некоторые алгебраические упрощения для целых чисел недопустимы, если вы требуете, чтобы переполнение знаковых целых арифметических выражений было четко определено.
Вот это например. Unspecified означает, что переполнение знаковых целых может быть 0, 1, -2 миллиарда, 5, и вообще какое угодно число. Ну и делайте свои алгебраические упрощения.
UB означает, что переполнение знаковых целых может быть «отформатировать жесткий диск» или «запустить ядерные ракеты». Не подскажете, зачем вам это для алгебраических упрощений?
Вы путаете UB и unspecified
Ну например в Rust и Fortran есть гарантия non-aliasing — компилятор имеет право считать, что ничего не поменяет значение переменной, кроме записи в эту самую переменную. Это значительно проще, а также дает больший выигрыш по оптимизации.
Пропустил комментарий. А как это ваще связано с UB? Есть пустое тело цикла, цикл можно развернуть и удалить.
Идея в том, что UB помогает доказать, что цикл завершится рано или поздно?
Есть вот такая штука
https://pgloader.readthedocs.io/
А можно эту функцию отключить как-нибудь?
С первым ребенком Алиса оказывала большое дисциплинирующее влияние на дикцию.
Типа «давай старайся, говори разборчиво, иначе Алиса сказку не включит».
Младшей стараться не надо, Алиса и так поймет
Во сколько лет вы узнали, что HR и руководитель на стороне компании, а не на вашей стороне?
Тут есть ещё один момент. Если ваши финансовые отношения с заказчиком строятся по модели контрактной разработки fix price, заказчик в принципе не может получить качественный продукт и качественный код.
Спасибо большое!
Если кому интересно, я хотел комиксы для этой статьи сделать https://habr.com/ru/articles/825880/ но не дождался буквально пары дней. Теперь придется делать :-))
Ну и чё, не придумывалось, нет архитектора, штука большая и сложная. В части моего опыта тоже все было в изрядно плохом состоянии.
ЦарЕв. 39. А ты кто?
Недостаточно унижают или слишком много унижают?
А если вы продаете заказчику каждую задачу в отдельности (представляю такие контракты, это обычно типа поддержка какой-то системы и идёт поток мелких доработок), то вам каждую задачу надо оценивать. Соответственно и анализировать.
Все верно. В каком случае проще совершить глобальную ошибку в архитектуре? Если мы проверяем и обсуждаем ее заранее, до написания кода, или все изменения в архитектуре окажутся видны другим членам команды только на код ревью?