Читаем Программирование полностью

Прежде чем читать дальше, попробуйте выяснить, сколько ошибок вы можете найти в функции f()? В частности, какой из вызовов функции poor() может привести к краху программы?

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

1. Передается элемент неправильного типа (например, poor(&s0[0],s0.size()). Кроме того, вектор s0 может быть пустым, а в этом случае выражение &s0[0] является неверным.

2. Используется “магическая константа” (в данном случае правильная): poor(s1,10). И снова тип элемента неправильный.

3. Используется “магическая константа” (в данном случае неправильная): poor(s2,20).

4. Первый вызов poor(p1,1) правильный (в чем легко убедиться).

5. Передача нулевого указателя при втором вызове: poor(p1,1).

6. Вызов poor(q,max), возможно, правильный. Об этом трудно судить, глядя лишь на фрагмент кода. Для того чтобы выяснить, ссылается ли указатель q на массив, содержащий хотя бы max элементов, мы должны найти определения указателя q и переменной max и их значения при данном вызове.

В каждом из перечисленных вариантов ошибки были простыми. Мы не столкнулись с какими-либо скрытыми ошибками, связанными с алгоритмами и структурами данных. Проблема заключается в интерфейсе функции poor(), который предусматривает передачу массива по указателю и открывает возможности для появления массы ошибок. Кроме того, вы могли убедиться в том, насколько затрудняют анализ такие малопонятные имена, как p1 и s0. Тем не менее мнемонические, но неправильные имена могут породить еще более сложные проблемы.

Теоретически компилятор может выявить некоторые из этих ошибок (например, второй вызов poor(p1,1), где p1==0), но на практике мы избежали катастрофы в данном конкретном случае только потому, что компилятор предотвратил создание объектов абстрактного класса Shape. Однако эта ошибка никак не связана с плохим интерфейсом функции poor(), поэтому мы не должны расслабляться. В дальнейшем будем использовать вариант класса Shape, который не является абстрактным, так что избежать проблем с интерфейсом нам не удастся.

Как мы пришли к выводу, что вызов poor(&s0[0],s0.size()) является ошибкой. Адрес &s0[0] относится к первому элементу массива объектов класса Circle; он является значением указателя Circle*. Мы ожидаем аргумент типа Shape* и передаем указатель на объект класса, производного от класса Shape (в данном случае Circle*). Это вполне допустимо: нам необходимо такое преобразование, чтобы можно было обеспечить объектно-ориентированное программирование и доступ к объектам разных типов с помощью общего интерфейса (в данном случае с помощью класса Shape) (см. раздел 14.2). Однако функция poor() не просто использует переменную Shape* как указатель; она использует ее как массив, индексируя ее элементы.

for (int i = 0; i

Иначе говоря, она ищет элементы, начиная с ячеек &p[0], &p[1], &p[2] и т.д.

В терминах адресов ячеек памяти эти указатели находятся на расстоянии sizeof(Shape) друг от друга (см. раздел 17.3.1). К сожалению для модуля, вызывающего функцию poor(), значение sizeof(Circle) больше, чем sizeof(Shape), поэтому схему распределения памяти можно проиллюстрировать так.

Другими словами, функция poor() вызывает функцию draw() с указателем, ссылающимся в середину объекта класса Circle! Это скорее всего приведет к немедленной катастрофе (краху)!

  Вызов функции poor(s1,10) носит более коварный характер. Он использует “магическую константу”, поэтому сразу возникает подозрение, что могут возникнуть проблемы при сопровождении программы, но это более глубокая проблема. Единственная причина, по которой использование массива объектов класса Polygon сразу не привело к проблемам, которые мы обнаружили при использовании объектов класса Circle, заключается в том, что класс Polygon не добавляет члены класса к базовому классу Shape (в отличие от класса Circle; см. разделы 13.8 и 13.12), т.е. выполняется условие sizeof(Shape)==sizeof(Polygon) и — говоря более общо — класс Polygon имеет ту же самую схему распределения памяти, что и класс Shape. Иначе говоря, нам просто повезло, так как небольшое изменение определения класса Polygon приведет программу к краху. Итак, вызов poor(s1,10) работает, но его ошибка похожа на мину замедленного действия. Этот код категорически нельзя назвать качественным.

То, с чем мы столкнулись, является основанием для формулировки универсального правила, согласно которому из утверждения “класс D — это разновидность класс B” не следует, что “класс Container — это разновидность класса Container” (см. раздел 19.3.3). Рассмотрим пример.