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

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<sz; ++i) p[i].draw();

Иначе говоря, она ищет элементы, начиная с ячеек

&p[0]
,
&p[1]
,
&p[2]
и т.д.

Программирование. Принципы и практика использования C++ Исправленное издание - _309.png

В терминах адресов ячеек памяти эти указатели находятся на расстоянии

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

Программирование. Принципы и практика использования C++ Исправленное издание - _310.png

Другими словами, функция

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

 

Программирование. Принципы и практика использования C++ Исправленное издание - _003.png
 Вызов функции
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<D>
— это разновидность класса
Container<B>
” (см. раздел 19.3.3). Рассмотрим пример.

class Circle:public Shape { /* ... */ };

void fv(vector<Shape>&);

void f(Shape &);

void g(vector<Circle>& vd, Circle & d)

{

  f(d);   // OK: неявное преобразование класса Circle в класс Shape

  fv(vd); // ошибка: нет преобразования из класса vector<Circle>

          // в класс vector<Shape>

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