BD
ну вот видишь, подробно написано, с ворнингами, в плюсовой документации такого нету
Size: a a a
2020 August 10
p
любой unsafe - UB
unsafe { 0 }
тут нет ub
тут нет ub
Ct
unsafe { 0 }
тут нет ub
тут нет ub
Сегодня - нет, а завтра вполне может быть.
BD
любой unsafe - UB
ну вообще clippy требует к каждому блоку unsafe немного описания почему это не UB, так что нет
CD
unsafe { 0 }
тут нет ub
тут нет ub
это гарантируется документацией?
p
Сегодня - нет, а завтра вполне может быть.
если апнут версию до rust 2 то может быть
p
а так ломать обратную совместимость не будут
Ct
если апнут версию до rust 2 то может быть
Кор тима сама еще не знает что валидно, что нет. Если твой пример на чуть более сложный заменить, то уже станет не так очевидно.
CD
ну вообще clippy требует к каждому блоку unsafe немного описания почему это не UB, так что нет
А какие его аксиомы? Где дока "вот это точно не UB"?
p
это гарантируется документацией?
это гарантируется реализацией
CD
это гарантируется реализацией
реализация является источником документации или нет? ты не ответил
Ct
По std раскиданы unsafe блоки над которыми явно написано, что "вот тут формально может быть UB, но мы знаем как компилятор устроен, так что нам можно"
BD
@MRSMITH4 алое
BD
CD
Что такое "возникает любая аксиома для компилятора"?
Например, компилятор предполагает результат
mov eax, 1
mov ebx, 2
add eax, ebx
DS
Т-34 85
>по Парето 80/20: только 20% кода требуют оптимизации, которые принесут 80% производительности.
В случае с бездумным использованием LINQ на ряде проектов это просто не работает. В профайлере видна картина, когда нет конкретного места, которое тормозит. И это очень и очень дорого потом исправлять.
В случае с бездумным использованием LINQ на ряде проектов это просто не работает. В профайлере видна картина, когда нет конкретного места, которое тормозит. И это очень и очень дорого потом исправлять.
Смотрится это беспочвенным утверждением.
Потому что в куче приложений которые я профилировал всегда были ярко выраженные горячие зоны в вычислениях.
Ну и да, на надо использовать язык типа C# в cpu bound задачах
Потому что в куче приложений которые я профилировал всегда были ярко выраженные горячие зоны в вычислениях.
Ну и да, на надо использовать язык типа C# в cpu bound задачах
CD
По std раскиданы unsafe блоки над которыми явно написано, что "вот тут формально может быть UB, но мы знаем как компилятор устроен, так что нам можно"
В С++ это аналогично. Это не документация. std так можно, тебе нельзя
BD
Например, компилятор предполагает результат
mov eax, 1
mov ebx, 2
add eax, ebx
это выглядит похожим на результат котогенерации, причем тут компилятор)
CD
это выглядит похожим на результат котогенерации, причем тут компилятор)
при том, что он ожидает увидеть здесь 3, это необходимо для матча языкового + на процессорный
Ct
В С++ это аналогично. Это не документация. std так можно, тебе нельзя
Окей, там еще есть проблемы вида "мы сами не знаем UB ли это и что с этим делать"