Литмир - Электронная Библиотека
A
A

Рассмотрим эти ошибки.

1. При вызове функции

arena(7)
мы сделали опечатку: вместо
area
набрали arena, поэтому компилятор думает, что мы хотим вызвать функцию с именем
arena
. (А что еще он может “подумать”? Только то, что мы сказали.) Если в программе нет функции с именем
arena()
, то вы получите сообщение об ошибке, связанной с необъявленной функцией. Если же в программе есть функция с именем
arena
, принимающая число
7
в качестве аргумента, то вы столкнетесь с гораздо худшей проблемой: программа будет скомпилирована как ни в чем ни бывало, но работать будет неправильно (такие ошибки называют логическими; см. раздел 5.7).

 2. Анализируя выражение

area(7)
, компилятор обнаруживает неправильное количество аргументов. В языке C++ вызов каждой функции должен содержать ожидаемое количество аргументов, указанных с правильными типами и в правильном порядке. Если система типов используется корректно, она становится мощным инструментом, позволяющим избежать ошибок на этапе выполнения программы (см. раздел 14.1).

3. Записывая выражение

area("seven",2)
, вы могли рассчитывать, что компилятор увидит строку "
seven
" и поймет, что вы имели в виду целое число
7
. Напрасно. Если функция ожидает целое число, то ей нельзя передавать строку. Язык C++ поддерживает некоторые неявные преобразования типов (см. раздел 3.9), но не позволяет конвертировать тип
string
в тип
int
. Компилятор даже не станет угадывать, что вы имели в виду. А что вы могли бы ожидать от вызовов
area("Hovel lane",2)
,
area("7,2")
и
area("sieben","zwei")
?

Мы перечислили лишь несколько примеров. Существует намного больше ошибок, которые компилятор может найти в вашей программе.

ПОПРОБУЙТЕ

Попробуйте скомпилировать эти примеры и проанализируйте сообщения компилятора. Придумайте еще несколько ошибок и проверьте их с помощью компилятора.

5.3.3. Не ошибки

Работая с компилятором, вы в какой-то момент захотите, чтобы он угадывал ваши намерения; иначе говоря, захотите, чтобы некоторые ошибки он не считал таковыми. Это естественно. Однако удивительно то, что по мере накопления опыта вы захотите, чтобы компилятор был более придирчивым и браковал больше, а не меньше выражений. Рассмотрим пример.

int x4 = area(10,–7); // OK: но что представляет собой прямоугольник,

                      // у которого ширина равна минус 7?

int x5 = area(10.7,9.3);  // OK: но на самом деле вызывается area(10,9)

char x6 = area(100,9999); // OK: но результат будет усечен

Компилятор не выдаст никаких сообщений о переменной

x4
. С его точки зрения вызов
area(10,–7)
является правильным: функция
area()
запрашивает два целых числа, и вы их ей передаете; никто не говорил, что они должны быть положительными.

Относительно переменной

x5
хороший компилятор должен был бы предупредить, что значения типа
double
, равные 10.7 и 9.3, будут преобразованы в значения типа
int
, равные
10
и
9
(см. 3.9.2). Однако (устаревшие) правила языка утверждают, что вы можете неявно преобразовать переменную типа
double
в переменную типа
int
, поэтому у компилятора нет никаких оснований отвергать вызов
area(10.7,9.3)
.

Инициализация переменной

x6
представляет собой вариант той же проблемы, что и вызов
area(10.7,9.3)
. Значение типа
int
, возвращенное после вызова
area(100,9999)
, вероятно, равное
999900
, будет присвоено переменной типа
char
. В итоге, скорее всего, в переменную
x6
будет записано “усеченное” значение
–36
. И опять-таки хороший компилятор должен выдать предупреждение, даже если устаревшие правила языка позволяют ему не делать этого.

По мере приобретения опыта вы научитесь использовать как сильные, так и слабые стороны компилятора. Однако не будьте слишком самоуверенными: выражение “программа скомпилирована” вовсе не означает, что она будет выполнена. Даже если она будет запущена на выполнение, то, как правило, сначала будет выдавать неправильные результаты, пока вы не устраните все логические недостатки.

5.4. Ошибки во время редактирования связей

 

Программирование. Принципы и практика использования C++ Исправленное издание - _001.png
 Любая программа состоит из нескольких отдельно компилируемых частей, которые называют единицами трансляции (translation units). Каждая функция в программе должна быть объявлена с теми же самыми типами, которые указаны во всех единицах трансляции, откуда она вызывается. Для этого используются заголовочные файлы (подробно о них речь пойдет в разделе 8.3). Кроме того, каждая функция должна быть объявлена в программе только один раз. Если хотя бы одно из этих правил нарушено, то редактор связей выдаст ошибку. Способы исправления ошибок во время редактирования связей рассматриваются в разделе 8.3. А пока рассмотрим пример программы, которая порождает типичную ошибку на этапе редактирования связей.

int area(int length, int width); // вычисляет площадь прямоугольника

int main()

{

  int x = area(2,3);

}

Если функция

area()
не объявлена в другом исходном файле и не связана с нашим файлом с помощью редактора связей, то он сообщит об отсутствии объявления функции
area()
.

Определение функции

area()
должно иметь точно такие же типы (как возвращаемого значения, так и аргументов), как и в нашем файле.

int area(int x, int y) { /* ... */ } // "наша" функция area()

Функции с таким же именем, но с другими типами аргументов будут проигнорированы.

double area(double x, double y) { /* ... */ }   // не "наша" area()

61
{"b":"847443","o":1}