в качестве аргумента и — каким-то образом — немедленно преобразовывает его в ссылку
Simple_window&
:
reference_to<Simple_window>(addr)
Функция
reference_to
является шаблонной (раздел A.13).
template<class W>W& reference_to(Address pw)
// интерпретирует
адрес как ссылку на объект класса W
{
return *static_cast<W*>(pw);
}
Здесь мы использовали шаблонную функцию, для того чтобы самостоятельно написать операции, действующие как приведение типа
void*
к типу
Simple_window&
. Это приведение типа
static_cast
описано в разделе 17.8.
Компилятор не имеет возможности проверить наши предположения о том, что аргумент
addr
ссылается на объект класса
Simple_window
, но правила языка требуют, чтобы компилятор в этом вопросе доверял программисту. К счастью, мы оказались правы. Об этом свидетельствует от факт, что система FLTK возвращает нам обратно указатель, который мы ей передавали. Поскольку, передавая указатель системе FLTK, мы знали его тип, можно использовать функцию
reference_to
, чтобы “получить его обратно”. Все это немного запутанно, не проходит проверку и не больше характерно для низкоуровневого программирования.
Получив ссылку на объект класса
Simple_window
, мы можем использовать ее для вызова функции-члена класса
Simple_window
. Рассмотрим пример (раздел 16.3).
void Simple_window::cb_next(Address, Address pw)
// вызов функции Simple_window::next для окна,
// расположенного по адресу pw
{
reference_to<Simple_window>(pw).next;
}
Мы использовали довольно сложную функцию обратного вызова
cb_next
, просто чтобы согласовать типы, необходимые для вызова совершенно обычной функции-члена
next
.
Д.2. Реализация класса Widget
Наш интерфейсный класс
Widget
выглядит следующим образом.
class Widget {
// Класс Widget — это дескриптор класса Fl_widget,
// а не сам класс Fl_widget;
// мы пытаемся не смешивать наши интерфейсные классы с FLTK
public:
Widget(Point xy, int w, int h, const string& s, Callback cb)
Fl_Widget* pw; // каждый объект класса Widget о "своем"
// классе Fl_Widget
};
Обратите внимание на то, что наш класс
Widget
следит за “своим” компонентом библиотеки FLTK и классом
Window
, с которыми он связан. Кроме того, отметьте, что для этого нам необходимы указатели, поскольку объект класса
Widget
на протяжении времени своего существования может быть связан с разными объектами класса
Window
. Ссылки или именованного объекта для этого недостаточно. (Объясните почему?)
Объект класса
Widget
имеет местоположение (
loc
), прямоугольную форму (
width
и
height
), а также сметку (
label
. Интересно, что он также имеет функцию обратного вызова (
do_it
), т.е. связывает образ объекта класса
Widget
на экране с фрагментом своего кода. Смысл операций
move
,
show
,
hide
и
attach
должен быть очевидным.
Класс
Widget
выглядит незаконченным. Он спроектирован как класс реализации, который пользователи не должны видеть слишком часто. Его стоит переделать. Мы подозреваем, что все эти открытые члены и “очевидные” операции содержат подводные камни.
Класс
Widget
имеет виртуальную функцию и может быть использован как базовый класс, поэтому в нем предусмотрен виртуальный деструктор (см. раздел 17.5.2).
Д.3. Реализация класса Window
Когда следует использовать указатели, а когда ссылки? Мы обсудили этот общий вопрос в разделе 8.5.6. Здесь мы лишь отметим, что некоторые программисты любят указатели и что нам нужны указатели, когда мы хотим сослаться на разные объекты в разные моменты времени.
До сих пор мы скрывали главный класс в нашей графической библиотеке — класс
Window
. Основная причина этого заключалась в том, что он использует указатели, а его реализация с помощью библиотеки FLTK опирается на использование свободной памяти. Вот как описан этот класса в заголовочном файле