пользователь об этом может и не знать, а сам компилятор убедиться в этом не способен. Из-за интенсивного использования указателей и ссылок в С++ возможно появление большого числа оп1ибок, и опыт Fortran тут ничего не доказывает;

□ альтернативы предложению недостаточно исследованы. Во многих случаях можно было бы провести начальную проверку на перекрытие и при его отсутствии выбрать оптимизированный вариант алгоритма. В других случаях стоит обратиться к специализированным математическим библиотекам (например, BLAS), которые имеют специальную поддержку для векторных операций. Еше предстоит изучить многообещающие альтернативные способы опти.мизации. Например, глобальная оптимизация относительно небольших и легко распознаваемых участков кода, где встречаются операции с векторами и матрицами, представляется вполне реализуемой в кохтиляторах С++ для высокопроизводительных компьютеров;

□ расширение зависит от архитектуры. Высокопроизводительные численные расчеты - это специальная область со свои.ми методами, зачастую предполагающая наличие особой аппаратуры. Поэтому лучше ввести нестандартное архитектурно-зависимое расширение или прагму. Если же такого рода оптимизация окажется полезной и более широкому кругу пользователей, то к рассмотрению этого расширения можно будет вернуться.

Принятое решение еще раз подтверждает, что С++ поддерживает абстрагирование за счет общих механизмов, а не специализированные приложения путем реализации специальных средств. Конечно, я хотел бы по.мочь людям, занимающимся численными расчетами, но как? Идти по стопам Fortran в реализации классических векторных и матричных алгоритмов - это далеко не всегда самый лучший путь. Было бы хорошо, если бы любую расчетную програм.му можно было написать на С++ без потери эффективности, но если не удастся достичь этого, не принося в жертву систему контроля типов С++, то, видимо, стоит обратиться к Fortran, ассемблеру или архитектурно-зависимы.м расширениям.

6.5.3. Наборы символов

Язык С ориентирован на американский вариант международного 7-битного набора символов ISO 646-1983, называемого также ASCII (ANSI3.4-1968). Это порождает две проблемы:

□ код ASCII содержит некоторые знаки препинания и специальные си.мволы, например ] или {, которых нет во многих национальных наборах символов;

□ В коде ASCII отсутствуют символы типа Е и ж, которых нет в английском алфавите.

6.5.5.7. Ограниченные наборы символов

В коде ASCII (ANSI3.4-1968) специальные символы [,],{,}, I и \ занимают позиции, которые по стандарту ISO отведены под буквы. В большинстве европейских национальных наборов символов ISO-646 эти позиции заняты буква.ми.

которых нет в английском алфавите. Например, в датском наборе символов на этих местах находятся гласные Ж, А, ае, , и и 0, без которых невозможно написать сколько-нибудь осмысленный датский текст. Это ставит датских программистов перед неприятным выбором: либо приобретать компьютеры, на которых есть полный 8-битный набор символов (например, ISO-8859/1/2), либо не использовать три гласные буквы своего родного языка, либо не программировать на С++. Люди, говорящие на немецком, французском, испанском, итальянском и других языках, сталкиваются с той же проблемой. Кстати, данное недоразумение стало серьезным препятствием на пути признания С в Европе, особенно в коммерческих приложениях (к примеру, банковских системах), поскольку 7-битные национальные наборы символов во многих странах используются повсеместно.

Рассмотрим, например, безобидную, на первый взгляд, профамму на ANSI С и С++:

int main(int argc, char* argv[]) {

if (argc<l II *argv[l] == \0) return 0; printf( Hello, %s\n ,argv[l]);

Ha стандартном датском терминале или принтере она будет выглядеть так:

int main (int argc, char* argvEA ) ae

if (argc<l ии *argvlA == 00) return 0; printf ( Hello, %s0n ,argvJElA) ;

&

Комитет ANSI С одобрил частичное решение проблемы, определив набор триграфов, с помощью которых можно вводить символы национальных алфавитов:

# [ { \ ] } I ~ 77= 77( 77< 77/ 77) 77> 77 771 77-

Возможно, для обмена профаммами это и имеет смысл, но удобочитаемость записи остается на прежнем уровне:

int maindnt argc, char* argv??(??)) ??<

if (argc<l ??!??! *argv??(l??) == ??/0) return 0; printf( Hello, %s??/n ,argv??{l??));

??>

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

%>

Замечу, что триграфы все-таки необходимы для вставки таких отсутствующих символов, как \, в строки и символьные константы.

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

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

Показанные в табл. 6.1 слова и диграфы являются эквивалентами операторов,