Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Программирование на C / C++ / C++ for real programmers.pdf
Скачиваний:
262
Добавлен:
02.05.2014
Размер:
2.04 Mб
Скачать

Невидимые

12

 

указатели

 

Нетривиальное использование С++ напоминает один известный эпизод из фильма «Сумеречная зона». Героиня попадает в автомобильную аварию. Она безуспешно ждет, пока кто-нибудь проедет по дороге, и в конце концов решает отправиться за помощью. Но куда бы она ни шла, как бы внимательно ни следила за направлением, она всегда возвращалась к обломкам машины. Так и с указателями: куда бы вы ни шли, вы все равно вернетесь к обломкам. Хм… пожалуй, мне следовало подыскать более оптимистичное сравнение.

В этой главе мы снова возвращаемся к теме указателей, на этот раз — в свете гомоморфных иерархий классов. Рассматриваемые здесь указатели я называю невидимыми (invisible pointers), поскольку в большинстве случаев можно устроить так, чтобы клиент абсолютно ничего не знал о присутствии указателя между ним и целевым объектом. Джеймс Коплин (James Coplien) рассматривает частный случай невидимых указателей и называет его «парадигма конверт/письмо»; мы же поговорим о более общем случае.

Основные концепции

Если гомоморфизм хорошо подходит для других классов, значит, он подойдет и для указателей. Концепция проста: указатель и указываемый объект порождаются от одного и того же чисто абстрактного базового класса.

class Foo { public:

virtual void do_something() = 0; virtual void do_something_else() = 0;

};

class PFoo : public Foo { private:

Foo* foo; public:

virtual void do_something() { foo->do_something(); }

virtual void do_something_else() { foo->do_something_else(); }

};

class Bar : public Foo {

// Все для производного класса

};

Вместо перегрузки оператора -> в PFoo используется делегирование. Приведенный фрагмент лишь слегка затрагивает данную тему. На практике приходится учитывать множество деталей, начиная с того, как скрыть указатели и указываемые объекты от клиентов.

180

Инкапсуляция указателей и указываемых объектов

Одно из величайших преимуществ гомоморфных указателей заключается в том, что указатель вместе с указываемым объектом можно инкапсулировать в файле .cpp. Взгляните на только что приведенный фрагмент. Указатель ничего не добавляет к открытому интерфейсу, представленному в классе Foo, поэтому клиентам не нужно видеть PFoo или производные классы, на которые он ссылается. В сущности, при достаточной аккуратности можно убедить клиентов, что они работают непосредственно с указываемым объектом, хотя на самом деле в качестве центрального звена цепочки присутствует указатель. Отсюда и термин — невидимый указатель.

// В файле foo.h class Foo { public:

static Foo* make(); // Производящая функция virtual void do_something() = 0;

virtual void do_something_else() = 0;

};

// В файле foo.cpp

class PFoo : public Foo { private:

Foo* foo; public:

PFoo(Foo* f) : foo(f) {}

virtual void do_something() { foo->do_something(); }

virtual void do_something_else() { foo->do_something_else(); }

};

class Bar : public Foo {

// Все для производного класса

};

Foo* Foo::make()

{

return new PFoo(new Foo);

}

Вставить PFoo в существующую программу совсем несложно — при условии, что вы приняли все меры предосторожности, спроектировали его с расчетом на гомоморфную иерархию классов и инкапсулировали производные классы вроде Bar. Ведь вы это сделали, не правда ли? Перед нами очередной мистический принцип — вы делаете что-то не для того, чтобы извлечь непосредственную пользу, а для сохранения мировой гармонии. В один прекрасный день вам потребуется вставить умный указатель, и в гармоничном мире это не вызовет никаких проблем.

Производящие функции

Конечно, производящие функции пригодятся вам каждый раз, когда вы инкапсулируете производные классы. В приведенном выше фрагменте мы изменили производящую функцию так, чтбы она создавала два объекта — указатель и указываемое значение.

Обратите внимание: указываемый объект не создается в конструкторе указателя. Для этого существует веская причина. Вероятно, нам захочется использовать класс указателя PFoo для всех производных классов Foo. Это означает, что некто за пределами класса указателя (производящая функция) решает, что именно следует создать и спрятать в указателе.

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

181

Все, что говорилось о производящих функциях и объектах классов в предыдущей главе, в равной степени относится и к невидимым указателям. Оптимизируйте и локализуйте, сколько душе угодно. Как правило, сам класс указателя в этом не участвует.

Ссылки на указатели

Производящая функция не обязана возвращать Foo*. С таким же успехом подойдет и Foo&. class Foo {

public:

static Foo& make(); // Производящая функция virtual void do_something() = 0;

virtual void do_something_else() = 0;

};

// В файле foo.cpp

class PFoo : public Foo { private:

Foo* foo; public:

PFoo(Foo* f) : foo(f) {}

virtual void do_something() { foo->do_something(); }

virtual void do_something_else() { foo->do_something_else(); }

};

class Bar : public Foo {

// Все для производного класса

};

Foo& Foo::make()

{

return *(new PFoo(new Foo));

}

Единственная проблема заключается в том, что копирование с помощью конструктора копий, как вы вскоре убедитесь, строго воспрещается. И все же люди, вооруженные оператором &, неизменно пытаются копировать объект. С оператором * соблазн намного слабее. Во всем остальном выбор — дело вкуса.

Неведущие указатели

Парадигма нивидимых указателей реализуется как для ведущих, так и неведущих указателей. От того, какое решение будет принято на стадии дизайна, зависят и способы решения некоторых проблем. Ниже приведены некоторые подробности реализации неведущих указателей.

Копирование

Клиент не может копировать указатель нормальными средствами, поскольку он не знает его настоящего класса. Зато хорошо подходят средства, описанные в предыдущей главе (в особенности копирование объектов с помощью специального виртуального варианта make-функции). Для неведущих указателей достаточно просто скопировать адрес указываемого объекта.

class Foo {

 

private:

 

Foo(const Foo&) {}

 

public:

 

virtual Foo* makeClone();

// Копирование

};

 

// В файле foo.cpp

 

182

class PFoo : public Foo { private:

Foo* foo; public:

PFoo(Foo* f) : foo(f) {}

virtual Foo* makeClone() { return new PFoo(foo); }

};

 

Foo* Foo::makeClone()

 

{

 

return NULL;

// Несущественно для всего, кроме указателей

}

 

Реализация функции makeClone() необходима только для класса указателя. По этой причине, чтобы каждому производному классу не пришлось ее переопределять, в класс-предок включается заглушка.

Присваивание

Разумеется, если не принять специальных мер, оператор = тоже не будет работать, поскольку клиент не знает фактический тип указателя. Так как мы имеем дело с неведущими указателями, операция присваивания стоит согласовать с копированием — то есть присваивание должно затрагивать только указатель, но не указываемый объект. Как и в случае копирования, это нетрудно реализовать — достаточно создать виртуальный оператор = для указателя и заглушку для указываемого объекта.

class Foo {

public:

virtual Foo& operator=(const Foo&);

};

// В файле foo.cpp

class PFoo : public Foo { private:

Foo* foo; public:

virtual Foo& operator=(const Foo& f)

{

foo = f.foo; return *this;

}

};

Foo& Foo::operator=(const Foo&)

{

return *this;

}

Сборка мусора: взгляд в будущее

Поскольку производные классы инкапсулированы, применение неведущих указателей подводит нас к серьезной проблеме дизайна: как узнать, когда нужно удалять указываемый объект? В главах, посвященных управлению памятью, мы серьезно займемся этой проблемой, а пока я лишь в общих чертах опишу две базовые стратегии:

1. В указываемый объект включается счетчик, который показывает, сколько указателей ссылается на него в данный момент. Когда состояние счетчика изменяется с 1 на 0, объект должен удалять себя.