case 0: cout «„ „case 0\n“; case1: case 1: cout „„ «case 1\n“; return; case 2; cout «« «case 2\n“; goto case1; default: cout «« «default: case не найден\n“; return; *)

При обращении к нему с val==2 выдаст

case 2 case 1

Заметьте, что метка case не подходит как метка для упоребления в операторе goto:

goto case 1; // синтаксическая ошибка

С++ снабжен имеющим дурную репутацию оператором goto.

goto идентификатор; идентификатор : оператор

В общем, в программировании высокого уровня он имеет очень мало применений, но он может быть очень полезен, когда С++ программа генерируется программой, а не пишется непоредственно человеком. Например, операторы goto можно исползовать в синтаксическом анализаторе, порождаемом генератором синтаксических анализаторов. Оператор goto может быть также важен в тех редких случаях, когда важна наилучшая эффектиность, например, во внутреннем цикле какой-нибудь программы, работающей в реальном времени.

Одно из немногих разумных применений состоит в выходе из вложенного цикла или переключателя (break лишь прекращает вполнение самого внутреннего охватывающего его цикла или преключателя). Например:

for (int i = 0; i«n; i++) for (int j = 0; j«m; j++) if (nm[i][j] == a) goto found // найдено // не найдено // ...

found: // найдено // nm[i][j] == a

Имеется также оператор continue, который по сути делает переход на конец оператора цикла, как объясняется в #3.1.5.

Продуманное использование комментариев и согласованное использование отступов может сделать чтение и понимание прораммы намного более приятным. Существует несколько различных стилей согласованного использования отступов. Автор не видит никаких серьезных оснований предпочесть один другому (хотя как и у большинства, у меня есть свои предпочтения). Сказаное относится также и к стилю комментариев.

Неправильное использование комментариев может серьезно повлиять на удобочитаемость программы, Компилятор не понимает содержание комментария, поэтому он никаким способом не может убедиться в том, что комментарий

1. осмыслен,

2. описывает программу и

3. не устарел.

Непонятные, двусмысленные и просто неправильные комметарии содержатся в большинстве программ. Плохой комментарий может быть хуже, чем никакой.

Если что-то можно сформулировать средствами самого язка, следует это сделать, а не просто отметить в комментарии. Данное замечание относится к комментариям вроде:

// переменная "v" должна быть инициализирована.

//переменная"v"должна использоваться только функцией «f».

// вызвать функцию init перед вызовом // любой другой функции в этом файле.

// вызовите функцию очистки «cleanup» в конце вашей // программы.

// не используйте функцию «wierd».

// функция «f» получает два параметра.

При правильном использовании С++ подобные комментарии как правило становятся ненужными. Чтобы предыдущие комментрии стали излишними, можно, например, использовать правила компоновки (#4.2) и видимость, инициализацию и правила очиски для классов (см. #5.5.2).

Если что-то было ясно сформулировано на языке, второй раз упоминать это в комментарии не следует. Например:

a = b+c; // a становится b+c count++; // увеличить счетчик

Такие комментарии хуже чем просто излишни, они увеличвают объем текста, который надо прочитать, они часто затумнивают структуру программы, и они могут быть неправильными.

Автор предпочитает:

1. Комментарий для каждого исходного файла, сообщающий, для чего в целом предназначены находящиеся в нем комментарии, дающий ссылки на справочники и руководства, общие рекомендции по использованию и т.д.,

2. Комментарий для каждой нетривиальной функции, в ктором сформулировано ее назначение, используемый алгоритм (если он неочевиден) и, быть может, что-то о принимаемых в ней предположениях относительно среды выполнения,

3. Небольшое число комментариев в тех местах, где прорамма неочевидна и/или непереносима и

4. Очень мало что еще.

Например:

// tbl.c: Реализация таблицы имен /* Гауссовское исключение с частичным См. Ralston: «A first course ...» стр. 411. */

// swap предполагает размещение стека AT amp;T sB20.