Нет никаких логических препятствий интерпретировать данный массив указателей типа
Circle*
как неизменяемый массив указателей типа
Shape*
(из контейнера
Array_ref
).
Похоже, что мы забрели на территорию экспертов. Эта проблема очень сложная, и ее невозможно устранить с помощью рассмотренных ранее средств. Однако, устранив ее, мы можем предложить почти идеальную альтернативу дисфункциональному, но все еще весьма популярному интерфейсу (указатель плюс количество элементов; см. раздел 25.4.2). Пожалуйста, запомните: никогда не заходите на территорию экспертов, просто чтобы продемонстрировать, какой вы умный. В большинстве случаев намного лучше найти
библиотеку, которую некие эксперты уже спроектировали, реализовали и протестировали для вас. Во-первых, мы переделаем функцию
better
так, чтобы она использовала указатели и гарантировала, что мы ничего не напутаем с аргументами контейнера.
void better2(const Array_ref<Shape*const> a)
{
for (int i = 0; i<a.size; ++i)
if (a[i])
a[i]–>draw;
}
Теперь мы работаем с указателями, поэтому должны предусмотреть проверку нулевого показателя. Для того чтобы гарантировать, что функция
better2
не модифицирует наш массив и векторы находятся под защитой контейнера
Array_ref
, мы добавили несколько квалификаторов
const
. Первый квалификатор
const
гарантирует, что мы не применим к объекту класса
Array_ref
модифицирующие операции, такие как
assign
и
reset
. Второй квалификатор
const
размещен после звездочки (
*
). Это значит, что мы хотим иметь константный указатель (а не указатель на константы); иначе говоря, мы не хотим модифицировать указатели на элементы, даже если у нас есть операции, позволяющие это сделать.
Далее, мы должны устранить главную проблему: как выразить идею, что объект класса
Это похоже на головоломку, но все же перечислим ее основные моменты.
• Оператор приводит каждый тип
Q
к типу
Array_ref<const Q>
, при условии, что мы можем преобразовать каждый элемент контейнера
Array_ref<T>
в элемент контейнера
Array_ref<Q>
(мы не используем результат этого приведения, а только проверяем, что такое приведение возможно).
• Мы создаем новый объект класса
Array_ref<const Q>
, используя метод решения “в лоб” (оператор
reinterpret_cast
), чтобы получить указатель на элемент желательного типа. Решения, полученные “в лоб”, часто слишком затратные; в данном случае никогда не следует использовать преобразование в класс
Array_ref
, используя множественное наследование (раздел A.12.4).
• Обратите внимание на квалификатор
const
в выражении
Array_ref<const Q>
: именно он гарантирует, что мы не можем копировать объект класса
Array_ref<const Q>
в старый, допускающий изменения объект класса
Array_ref<Q>
.
Мы предупредили вас о том, что зашли на территорию экспертов и столкнулись с головоломкой. Однако эту версию класса
Array_ref
легко использовать (единственная сложность таится в его определении и реализации).
void f(Shape* q, vector<Circle*>& s0)
{
Polygon* s1[10];
Shape* s2[20];
// инициализация
Shape* p1 = new Rectangle(Point(0,0),10);
better2(make_ref(s0)); // OK: преобразование
// в Array_ref<Shape*const>
better2(make_ref(s1)); // OK: преобразование
// в Array_ref<Shape*const>
better2(make_ref(s2)); // OK (преобразование не требуется)
better2(make_ref(p1,1)); // ошибка
better2(make_ref(q,max)); // ошибка
}
Попытки использовать указатели приводят к ошибкам, потому что они имеют тип
Shape*
, а функция
better2
ожидает аргумент типа
Array_ref<Shape*>
; иначе говоря, функция
better2
ожидает нечто, содержащее указатель, а не сам указатель. Если хотите передать функции
better2
указатель, то должны поместить его в контейнер (например, во встроенный массив или вектор) и только потом передать его функции. Для отдельного указателя мы можем использовать неуклюжее выражение
make_ref(&p1,1)
. Однако это решение не подходит для массивов (содержащих более одного элемента), поскольку не предусматривает создание контейнера указателей на объекты.
В заключение отметим, что мы можем создавать простые, безопасные, удобные и эффективные интерфейсы, компенсируя недостатки массивов. Это была основная цель данного раздела. Цитата Дэвида Уилера (David Wheeler): “Каждая проблема решается с помощью новой абстракции” считается первым законом компьютерных наук. Именно так мы решили проблему интерфейса.
25.5. Биты, байты и слова
Выше мы уже упоминали о понятиях, связанных с устройством компьютерной памяти, таких как биты, байты и слова, но в принципе они не относятся к основным концепциям программирования. Вместо этого программисты думают об объектах конкретных типов, таких как
double
,
string
,
Matrix
и
Simple_window
. В этом разделе мы заглянем на уровень программирования, на котором должны лучше разбираться в реальном устройстве памяти компьютера.
Если вы плохо помните двоичное и шестнадцатеричное представления целых чисел, то обратитесь к разделу A.2.1.1.
25.5.1. Операции с битами и байтами
Байт — это последовательность, состоящая из восьми битов.
Биты в байте нумеруются справа (от самого младшего бита) налево (к самому старшему). Теперь представим слово как последовательность, состоящую из четырех битов.
Нумерация битов в слове также ведется справа налево, т.е. от младшего бита к старшему. Этот рисунок слишком идеализирует реальное положение дел: существуют компьютеры, в которых байт состоит из девяти бит (правда, за последние десять лет мы не видели ни одного такого компьютера), а машины, в которых слово состоит из двух бит, совсем не редкость. Однако будем считать, что в вашем компьютере байт состоит из восьми бит, а слово — из четырех.