From 8c0ffdb791f2a1d184adce9cbca4caddef02ecca Mon Sep 17 00:00:00 2001 From: Dmitry Sviridkin Date: Sat, 24 Aug 2024 15:55:55 +0100 Subject: [PATCH] Update uninitialized.md --- runtime/uninitialized.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/runtime/uninitialized.md b/runtime/uninitialized.md index 106d875..a6aac08 100644 --- a/runtime/uninitialized.md +++ b/runtime/uninitialized.md @@ -6,6 +6,8 @@ C и C++ — старые языки. В них можно легко и просто объявить переменную, а инициализировать ее как-нибудь потом. Или забыть иницаилизировать вовсе. Но в отличие от совсем низкоуровневого ассемблера, в котором читать из неинициализированной переменной никто не запрещает — ну получите вы свои мусорные байтики и ладно — в C/C++ (а также в Rust, см [MaybeUninit](https://doc.rust-lang.org/std/mem/union.MaybeUninit.html)) это влечет за собой неопределенное поведение. +Но время не стоит на месте даже для C++ и в последних версиях стандарта (C++26 и новее) всё же произошли некоторые изменения: стандарт вводит новое понятие *ошибочного* *(errorneous)* поведения. И ошибка чтения неинициализированной переменной считается теперь ошибочным, а не неопределенным поведением. На практике же это значит, что вы все также успешно отстрелите себе ногу, но компиляторам рекомендуется выдать диагностику. + Неожиданный вариант такого UB можно наблюдать на следующем примере (взято [тут](https://stackoverflow.com/questions/54120862/does-the-c-standard-allow-for-an-uninitialized-bool-to-crash-a-program)): @@ -46,7 +48,6 @@ int main() // size_t len = strlen(whichString); // 4 или 5! size_t len = 5 - boolValue; ``` - -------------- Так если отсутствие неинициализированных переменных способствует оптимизациям, почему бы их не запретить совсем, с жесткой ошибкой компиляции?