История изменений
Исправление safocl, (текущая версия) :
ты забыл что нужно хранить изменяемое состояние явно в своём коде.
и прозрачность (любой студент поймет что здесь написано), и надёжность, и скорость, и меньше стресса на компилятор, и отсутствие необходимости требовать c++23
первые три вообще под сильным сомнением.
стресс компилятор мне кажется вообще не будет чуствовать.
ниже c++23 вообще не стоит делать проги — пожалуй теперь уже ниже c++26.
а то сплошь и рядом «хаки оптимизации производительности» из union-ов и float-to-int-to-float корвертаций с «магическими изменениями битиков вручную», а так же пакованные структуры с прямым доступом к их неоднобайтовым мемберам (без копирования из/в) — вот такое возможно тру-кодирование по мнению неких лиц...
некоторые прожекты прислушались к исправлениям/рефакторингам, однако многим вообще пофиг как получается, даже в прожектах системного толка.
некоторые да, не хотят почемуто видеть в своих кодовых базах явные алгоритмы вместо циклов, что по мне грустно и печально.
Хоть всякие `std::bit_cast` норм юзаться начались — уже радость. Жаль что вроде бы пока не сделали `std::start_lifetime_as` и `std::start_lifetime_as_array`
_
Исправление safocl, :
ты забыл что нужно хранить изменяемое состояние явно в своём коде.
и прозрачность (любой студент поймет что здесь написано), и надёжность, и скорость, и меньше стресса на компилятор, и отсутствие необходимости требовать c++23
первые три вообще под сильным сомнением.
стресс компилятор мне кажется вообще не будет чуствовать.
ниже c++23 вообще не стоит делать проги — пожалуй теперь уже ниже c++26.
а то сплошь и рядом «хаки оптимизации производительности» из union-ов и float-to-int-to-float корвертаций с «магическими изменениями битиков вручную», а так же пакованные структуры с прямым доступом к их неоднобайтовым мемберам (без копирования из/в) — вот такое возможно тру-кодирование по мнению неких лиц...
некоторые прожекты прислушались к исправлениям/рефакторингам, однако многим вообще пофиг как получается, даже в прожектах системного толка.
некоторые да, не хотят почемуто видеть в своих кодовых базах явные алгоритмы вместо циклов, что по мне грустно и печально.
Хоть всякие `std::bit_cast` норм юзаться начались — уже радость. Жаль что вроде бы пока не сделали `std::start_lifetime_as`и `std::start_lifetime_as_array`
_
Исправление safocl, :
ты забыл что нужно хранить изменяемое состояние явно в своём коде.
и прозрачность (любой студент поймет что здесь написано), и надёжность, и скорость, и меньше стресса на компилятор, и отсутствие необходимости требовать c++23
первые три вообще под сильным сомнением.
стресс компилятор мне кажется вообще не будет чуствовать.
ниже c++23 вообще не стоит делать проги — пожалуй теперь уже ниже c++26.
а то сплошь и рядом «хаки оптимизации производительности» из union-ов и float-to-int-to-float корвертаций с «магическими изменениями битиков вручную», а так же пакованные структуры с прямым доступом к их неоднобайтовым мемберам (без копирования из/в) — вот такое возможно тру-кодирование по мнению неких лиц...
некоторые прожекты прислушались к исправлениям/рефакторингам, однако многим вообще пофиг как получается, даже в прожектах системного толка.
некоторые да, не хотят почемуто видеть в своих кодовых базах явные алгоритмы вместо циклов, что по мне грустно и печально.
Хоть всякие std::bit_cast норм юзаться начались — уже радость. Жаль что вроде бы пока не сделали `std::start_lifetime_as`и `std::start_lifetime_as_array`
_
Исходная версия safocl, :
ты забыл что нужно хранить изменяемое состояние явно в своём коде.
и прозрачность (любой студент поймет что здесь написано), и надёжность, и скорость, и меньше стресса на компилятор, и отсутствие необходимости требовать c++23
первые три вообще под сильным сомнением.
стресс компилятор мне кажется вообще не будет чуствовать.
ниже c++23 вообще не стоит делать проги — пожалуй теперь уже ниже c++26.
а то сплошь и рядом «хаки оптимизации производительности» из union-ов и float-to-int-to-float корвертаций с «магическими изменениями битиков вручную», а так же пакованные структуры с прямым доступом к их неоднобайтовым мемберам (без копирования из/в) — вот такое возможно тру-кодирование по мнению неких лиц...