Почему действительно пробуют.. блоки выгоды требуют фигурных скобок?
В то время как в других операторах как то, если... еще можно избежать фигурных скобок, если существует только одна инструкция в блоке, Вы не можете сделать, это с попыткой... ловит блоки: компилятор не покупает его. Например:
try
do_something_risky();
catch (...)
std::cerr << "Blast!" << std::endl;
С кодом выше, g ++ просто говорит, что он ожидает '{' прежде do_something_risky (). Почему это различие поведения между попыткой... еще ловит и, скажем, если...?
Спасибо!
8 ответов
Не уверен, что вы используете .NET, но CLR использует скобки как флаги.
http://dotnet.sys-con.com/node/44398
Из статьи: "Таблица SEH (structure exception handling) состоит из набора положений, которые описывают структуру охраняемого кода. Таблица имеет набор двоичных флагов, которые описывают тип пункта обработки исключений: флаг Try Offset, который является началом блока охраняемого кода; флаг Try Length, который является длиной охраняемого кода; флаги Handler Offset и Handler Length, которые детализируют начало блока обработчика исключений и его длину; и флаг Class Token или Filter Offset, в зависимости от типа обработчика исключений, который был определен. Эта информация позволяет CLR определить, что делать при возникновении исключения. Она определяет начало охраняемого блока кода, код, который должен быть выполнен для исключения, и специальную семантику, связанную с фильтрацией или другими особыми обстоятельствами."
Я предполагаю, что другие фреймворки делают то же самое.
Не знаю почему, но одно преимущество состоит в том, что нет проблемы с зависанием. См. dangling-else для получения информации о неоднозначности, которая может возникнуть, когда фигурные скобки являются необязательными.
Вот какими они хотели быть. Нет оправдания, это закон.
Прямо из спецификации C++:
try-block:
try compound-statement handler-seq
Как вы можете видеть, все try-блокиожидают составного утверждения. По определению, составное утверждение - это несколько утверждений, заключенных в фигурные скобки.
Заключение всего в составное утверждение гарантирует, что для блока try будет создана новая область видимости. На мой взгляд, это также облегчает чтение.
Вы можете проверить это сами на странице 359 из Спецификации языка C++
Прочтите эту ссылку . Основная причина, по-видимому, связана с управлением областью действия и распределением объектов, которые необходимо создавать и уничтожать в случае реальных исключений.
Итак, я предполагаю, что авторы грамматики C ++ просят авторов g ++ (или любых стандартов, соответствующих компилятору C ++) подготовить его к худшим возможным случаям, и авторы g ++, похоже, сделали это.
Почему? Компромисс между безопасностью и обратной совместимостью.
Уроки, извлеченные из if ... else, показали, что необходимость в фигурных скобках устраняет ошибки. Теперь люди из ISO C ++ отдают предпочтение обратной совместимости с C, поэтому они не меняли синтаксис C для if ... else. Но новые конструкции требуют фигурных скобок для разграничения контролируемых блоков, поскольку они не появляются в старом коде C, и поэтому обратная совместимость не является проблемой.
В основном это потому, что
if (a)
int b = 10;
else
int b = 5;
b += 5;
Не получится, потому что if...else без {} - это синтаксическое сокращение для этого
if (a) {
int b = 10;
} else {
int b = 5;
}
b += 5;
которое явно говорит вам, что int b находится в другой области видимости, чем остальная часть программы.
Если я не ошибаюсь, следующее также не работает
a ? int b = 10 : int b = 5;
b += 5;
Конечно, ваш компилятор может оптимизировать этот код для вас... но технически он должен работать из-за диапазонов в операторе if/else.
Всякий раз, когда вы видите {}, вы определяете область действия программы.
-Stephen
Во-первых, так устроена грамматика.
Во-вторых, я считаю, что цель состоит в том, чтобы принудительно сгенерировать новую область для блоков исключений (поправьте меня, если я ошибаюсь).