Шрифт:
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]
и т.д. В терминах адресов ячеек памяти эти указатели находятся на расстоянии
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<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>
}
poor
очень плох, но можно ли рассматривать этот код с точки зрения встроенной системы; иначе говоря, следует ли беспокоиться о таких проблемах в приложениях, для которых важным является безопасность или производительность? Можем ли мы объявить этот код опасным при программировании обычных систем и просто сказать им: “Не делайте так”. Многие современные встроенные системы основаны на графическом пользовательском интерфейсе, который практически всегда организован в соответствии с принципами объектно-ориентированного программирования. К таким примерам относятся пользовательский интерфейс устройств iPod, интерфейсы некоторых мобильных телефонов и дисплеи операторов в системах управления полетами. Кроме того, контроллеры аналогичных устройств (например, множество электромоторов) образуют классические иерархии классов. Другими словами, этот вид кода — и, в частности, данный вид объявлений функции — вызывает особые опасения. Нам нужен более безопасный способ передачи информации о коллекциях данных, который не порождал бы значительных проблем.