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

Страуструп Бьерн
Шрифт:

Для того чтобы облегчить создание объектов класса

Array_ref
, напишем несколько вспомогательных функций.

template<class T> Array_ref<T> make_ref(T* pp, int s)

{

return (pp) ? Array_ref<T>(pp,s):Array_ref<T>(0,0);

}

Если мы инициализируем объект класса

Array_ref
указателем, то должны явно указать его размер. Это очевидный недостаток, поскольку, задавая размер, легко ошибиться. Кроме того, он открывает возможности для использования указателя, представляющего собой результат неявного преобразования массива производного класса в указатель базового класса, например указателя
Polygon[10]
в указатель
Shape*
(ужасная проблема, описанная в разделе 25.4.2), но иногда мы должны просто доверять программисту.

Мы решили проявить осторожность в отношении нулевых указателей (поскольку это обычный источник проблем) и пустых векторов.

template<class T> Array_ref<T> make_ref(vector<T>& v)

{

return (v.size) ? Array_ref<T>(&v[0],v.size):
Array_ref<T>(0,0);

}

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

vector
, хотя он часто не подходит для систем, в которых класс
Array_ref
может оказаться полезным. Причина заключается в том, что он обладает ключевыми свойствами, присущими контейнерам, которые здесь можно использовать (например, контейнерам, основанным на пулах; см. раздел 25.3.3).

В заключение предусмотрим обработку встроенных массивов в ситуациях, в которых компилятор знает их размер.

template <class T, int s> Array_ref<T> make_ref(T (&pp)[s])

{

return Array_ref<T>(pp,s);

}

Забавное выражение

T(&pp)[s]
объявляет аргумент
pp
ссылкой на массив из
s
элементов типа
T
. Это позволяет нам инициализировать объект класса
Array_ref
массивом, запоминая его размер. Мы не можем объявить пустой массив, поэтому не обязаны проверять, есть ли в нем элементы.

Polygon ar[0]; // ошибка: элементов нет

Используя данный вариант класса

Array_ref
, мы можем переписать наш пример.

void better(Array_ref<Shape> a)

{

for (int i = 0; i<a.size; ++i) a[i].draw;

}

void f(Shape* q, vector<Circle>& s0)

{

Polygon s1[10];

Shape s2[20];

// инициализация

Shape* p1 = new Rectangle(Point(0,0),Point(10,20));

better(make_ref(s0)); // ошибка: требуется Array_ref<Shape>

better(make_ref(s1)); // ошибка: требуется Array_ref<Shape>

better(make_ref(s2)); // OK (преобразование не требуется)

better(make_ref(p1,1)); // OK: один элемент

delete p1;

p1 = 0;

better(make_ref(p1,1)); // OK: нет элементов

better(make_ref(q,max)); // OK (если переменная max задана корректно)

}

Мы видим улучшения.

• Код стал проще. Программисту редко приходится заботиться о размерах объектов, но когда это приходится делать, они задаются в специальном месте (при создании объекта класса

Array_ref
), а не в разных местах программы.

• Проблема с типами, связанная с преобразованиями

Circle[]
в
Shape[]
и
Polygon[]
, и
Shape[]
, решена.

• Проблемы с неправильным количеством элементов объектов

s1
и
s2
решаются неявно.

• Потенциальная проблема с переменной max (и другими счетчиками элементов, необходимыми для использования указателей) становится явной — это единственное место, где мы должны явно указать размер.

• Использование нулевых указателей и пустых векторов предотвращается неявно и систематически.

25.4.4. Наследование и контейнеры

Что делать, если мы хотим обрабатывать коллекцию объектов класса

Circle
как коллекцию класса
Shape
, т.е. если действительно хотим, чтобы функция
better
(представляющая собой вариант нашей старой знакомой функции
draw_all
; см. разделы 19.3.2 и 22.1.3) реализовала полиморфизм? По существу, мы не можем этого сделать. В разделах 19.3.3 и 25.4.2 показано, что система типов имеет веские основания отказаться воспринимать тип
vector<Circle>
как
vector<Shape>
. По той же причине она отказывается принимать тип
Array_ref<Circle>
как
Array_ref<Shape>
. Если вы не помните, почему, то перечитайте раздел 19.3.3, поскольку данный момент очень важен, даже если это кажется неудобным.