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

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

Шрифт:

Более того, для того чтобы сохранить динамический полиморфизм, мы должны манипулировать нашими полиморфными объектами с помощью указателей (или ссылок): точка в выражении
a[i].draw
в функции
better
противоречит этому требованию. Когда мы видим в этом выражении точку, а не стрелку (
–>
), следует ожидать проблем с полиморфизмом

Что нам делать? Во-первых, мы должны работать с указателями (или ссылками), а не с самими объектами, поэтому следует попытаться использовать классы

Array_ref<Circle*>
,
Array_ref<Shape*>
и тому подобные, а не
Array_ref<Circle>
,
Array_ref<Shape>
и т.п.

Однако мы по-прежнему не можем конвертировать класс

Array_ref<Circle*>
в класс
Array_ref<Shape*>
, поскольку нам потом может потребоваться поместить в контейнер
Array_ref<Shape*>
элементы, которые не имеют типа
Circle*
. Правда, существует одна лазейка.

• Мы не хотим модифицировать наш объект класса

Array_ref<Shape*>
; мы просто хотим рисовать объекты класса
Shape
! Это интересный и совершенно особый случай: наш аргумент против преобразования типа
Array_ref<Circle*>
в
Array_ref<Shape*>
не относится к ситуациям, в которых мы не хотим модифицировать класс
Array_ref<Shape*>
.

• Все массивы указателей имеют одну и ту же схему (независимо от объектов, на которые они ссылаются), поэтому нас не должна волновать проблема, упомянутая в разделе 25.4.2.

Иначе говоря, не произойдет ничего плохого, если объект класса
Array_ref<Circle*>
будет интерпретироваться как неизменяемый объект класса
Array_ref<Shape*>
. Итак, нам достаточно просто найти способ это сделать. Рассмотрим пример

< image l:href="#"/>

Нет никаких логических препятствий интерпретировать данный массив указателей типа

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

Далее, мы должны устранить главную проблему: как выразить идею, что объект класса

Array_ref<Circle*>
можно конвертировать

• в нечто подобное объекту класса

Array_ref<Shape*>
(который можно использовать в функции
better2
);

• но только если объект класса

Array_ref<Shape*>
является неизменяемым.

Это можно сделать, добавив в класс

Array_ref
оператор преобразования.

template<class T>

class Array_ref {

public:

// как прежде

template<class Q>

operator const Array_ref<const Q>

{

// проверка неявного преобразования элементов:

static_cast<Q>(*static_cast<T*>(0));

// приведение класса Array_ref:

return Array_ref<const Q>(reinterpret_cast<Q*>(p),sz);

}

// как прежде

};

Это похоже на головоломку, но все же перечислим ее основные моменты.

• Оператор приводит каждый тип

Q
к типу
Array_ref<const Q>
, при условии, что мы можем преобразовать каждый элемент контейнера
Array_ref<T>
в элемент контейнера
Array_ref<Q>
(мы не используем результат этого приведения, а только проверяем, что такое приведение возможно).

  • Читать дальше
  • 1
  • ...
  • 404
  • 405
  • 406
  • 407
  • 408
  • 409
  • 410
  • 411
  • 412
  • 413
  • 414
  • ...

Ебукер (ebooker) – онлайн-библиотека на русском языке. Книги доступны онлайн, без утомительной регистрации. Огромный выбор и удобный дизайн, позволяющий читать без проблем. Добавляйте сайт в закладки! Все произведения загружаются пользователями: если считаете, что ваши авторские права нарушены – используйте форму обратной связи.

Полезные ссылки

  • Моя полка

Контакты

  • chitat.ebooker@gmail.com

Подпишитесь на рассылку: