if (i = 7) { предупреждение: присваивание константы в условии ...

...

if (Х&077 == 0) { предупреждение: выражение == как операнд для &

...

Даже первая версия Cfront (см. раздел 3.3) выдавала такие предупреждения. Они появились в результате осознанного проектного решения, а не были добавлены потом.

Много позже первое из этих предупреждений превратилось в ошибку - был введен запрет на определение новых типов в типах возвращаемых значений и аргументов.

2.7. Почему С?

На презентациях С with Classes меня часто спрашивали: Почему Вы использовали С? Почему не Pascal? Один из вариантов ответа можно найти в работе [Stroustrup, 1986с]:

И тогда, и сейчас безусловные предупреждения выдавались для преобразований long-int и double-int, поскольку я не вижу причин для признания их законными. Это просто результат определенного недоразумения - арифметика с плавающей точкой появилась в С до введения явных преобразований. Такие предупреждения устраивали пользователей. Более того, меня самого и многих других они не раз выручали. С преобразованием же int-char я ничего не мог сделать. И по сей день такие преобразования компилятор AT&T С++ пропускает без предупреждений.

Я решил выдавать безусловные предупреждения только в случаях, когда вероятность ошибки больше 90% , причем был учтен опыт компилятора С и верификатора Lint, которые чаще, чем хотелось бы, выдавали ложные предупреждения относительно того, что не мешало программе корректно работать. Поэтому программисты либо вообще игнорировали предупреждения компилятора, либо все же смотрели на них, но добрых чувств явно не испытывали. Итак, предупреждения используются для того, чтобы как-то компенсировать сложности, которые не удается устранить путем изменения языка из-за требования совместимости с С, а также для облегчения перехода с С на С++. Вот пример:

class X { ...

g(int i, int x, int j)

предупреждение: class X определен как тип значения, возвращаемого g() (вы не забыли ; после } ?) предупреждение: j не используется

С, конечно, не сомый чистый язык из всех существующих и не самый простой для применения, ток почему же ток много людей им пользуются? Вот причины:

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

□ эффективность. Семантика языка низкоуровневая , то есть фундаментальные понятия С непосредственно отображаются но фундаментальные понятия традиционного компьютера. Следовательно, можно без особого труда эффективно воспользоваться аппорот-ными ресурсами из С-прогроммы;

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

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

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

Во время работы над С with Classes я еще не сумел бы дать такую отшлифованную формулировку, но она правильно отражает суть того, что я и тогда считал важным в С и не хотел терять в С with Classes. Pascal считался игрушечным языком [Kernighan, 1981], поэтому более простым казалось добавить контроль типов к С, чем включать в Pascal возможности, необходимые для системного программирования. В то время я очень боялся совершить ошибки, в результате которых дизайнер - из-за неправильно понятого патернализма или просто по незнанию -создает язык, непригодный для реальной работы в важных областях. Прошедшие десять лет показали, что, взяв за основу С, я сумел остаться в основном русле системного программирования, как и намеревался. Плата - сложность языка - оказалась велика, но не непомерна.

В качестве альтернативы С и источника идей для С++ я рассматривал [Stroustrup, 1984с] такие языки, как Modula-2, Ada, Smalltalk, Mesa [Mitchell, 1979] и Clu. Но лишь только С, Simula, AlgolGS и в одном случае BCPL оставили заметный след в С++ образца 1985 г. Из Simula я позаимствовал классы, из AlgolGS - перегрузку операторов (см. раздел 3.6), ссылки (см. раздел 3.7) и возможность объявлять переменные в любом месте блока (см. раздел 3. И.5), а у BCPL - обозначение для комментариев (см. раздел 3.11.1).

Были и другие причины избегать резких расхождений со стилем С. Достаточно серьезным вызовом мне представлялось уже само объединение сильных сторон С как

языка системного программирования с возможностями Simula по организации программ. Добавление нетривиальных возможностей из других источников легко могло бы привести к появлению конгломерата типа чего изволите вместо целостного языка. Приведу цитату из работы [Stroustrup, 1986]:

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

Как и в предыдущем случае, я бы не сумел дать такую формулировку во время ранних этапов работы над С with Classes, но общая идея понятна. Отход от известных и проверен}1ых временем методов программирования на С и Simula следовало отложить до приобретения достаточного опыта работы с С with Classes и С++. Еще предстояло провести немало экспериментов. Я верю и верил, что проектирование языка - не просто следование заранее определенным принципам, а искусство, требующее опыта, экспериментирования и компромиссов. Включение в язык важной особенности должно быть обдуманным действием, основанным на опыте. Новой возможности необходимо сочетаться с уже имеющимися и не противоречить представлениям о том, как может использоваться язык. На развитие С++ после 1985 г. влияли Ada (шаблоны, см. главу 15; исключения, см. главу 16; пространства имен, см. главу 17), Clu (исключения, см. главу 16) и ML (исключения, см. главу 16).

2.8. Проблемы синтаксиса

Мог ли я устранить наиболее досадные недостатки синтаксиса и семантики языка С до того, как С++ стал общедоступным языком программирования? Мог ли я добиться этого, не отбросив в сторону некоторые полезные свойства, затрагивающие пользователей С with Classes, утонувших в своей среде, которую часто противопоставляют идеальному миру, или сделать этот язык несовместимым с другими, что неприемлемо для программистов на С, желающих перейти на С with Classes?

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

2.8.1. Синтаксис объявлений в языке С

Больше всего в С мне не нравился синтаксис объявлений. Наличие одновременно префиксных и постфиксных операторов объявлений - источник многих недоразумений. Например:

int *р[10]; /* массив из 10 указателей на int или */ /* указатель на массив из 10 int? */