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

Страуструп Бьерн

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, интерфейсы некоторых мобильных телефонов и дисплеи операторов в системах управления полетами. Кроме того, контроллеры аналогичных устройств (например, множество электромоторов) образуют классические иерархии классов. Другими словами, этот вид кода — и, в частности, данный вид объявлений функции — вызывает особые опасения. Нам нужен более безопасный способ передачи информации о коллекциях данных, который не порождал бы значительных проблем.

Итак, мы не хотим передавать функциям встроенные массивы с помощью указателей и размера массива. Чем это заменить? Проще всего передать ссылку на контейнер, например, на объект класса vector. Проблема, которая возникла в связи с интерфейсом функции

void poor(Shape* p, int sz);

исчезает при использовании функции

void general(vector<Shape>&);

Если вы программируете систему, в которой допускаются объекты класса

std::vector

(или его эквиваленты), то просто последовательно используйте в интерфейсах класс

vector

(или его эквиваленты) и никогда не передавайте встроенный массив с помощью указателя и количества элементов.

Если вы не можете ограничиться использованием класса

vector

или его эквивалентов, то оказываетесь на территории, где не бывает простых решений, — даже несмотря на то, что использование класса (

Array_ref

) вполне очевидно.

25.4.3. Решение: интерфейсный класс

К сожалению, во многих встроенных системах мы не можем использовать класс

std::vector

, потому что он использует свободную память. Мы можем решить эту проблему, либо предложив особую реализацию класса

vector

, либо (что более просто) используя контейнер, напоминающий класса

vector

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