C++: библиотека программиста

 
105 
Если обратиться к классу 
Foo
с запросом на получение 
Вlob
, он вернет вам то, на что ссылается его 
собственная переменная. Если запросить 
Bar
, а затем у 
Bar
запросить 
Blob
, вы получите другой 
объект — тот, на который ссылается 
Bar
. 
Такая ситуация обычно встречается при множественном наследовании и многократном (хотя и 
косвенном) наследовании от одного базового класса. Если переработать приведенный выше фрагмент, 
ту же проблему можно легко воссоздать с применением наследования: 
class Blob { ... }; 
class Foo : public Blob { ... }; 
class Bar : public Foo, public Blob { ... }; 
В этом фрагменте заложена неоднозначность. При преобразовании типа 
Bar*
в 
Blob*
непонятно, 
какой же 
Blob
имеется в виду: непосредственно базовый для 
Bar
или тот, от которого происходит 
Foo
? Даже если вам удастся справиться с неоднозначностью, транзитивность все равно нарушается. 
Как же избежать подобных проблем? Я мог бы пуститься в замысловатые объяснения, но все сводится 
к одному: следите за собой. Не наследуйте открыто от одного класса несколько раз в иерархическом 
дереве некоторого класса (с закрытым наследованием проблем обычно не возникает, поскольку нельзя 
выполнить преобразование к типу закрытого базового класса). Не внедряйте экземпляры одного класса 
в качестве переменных более чем одного компонента, а если уж вы это сделали — не предоставляйте 
интерфейсы более чем к одному из них. 
Устойчивость граней 
В эталонном C++ эта проблема возникает, например, при получении адреса переменной или базового 
класса и последующем удалении вмещающего объекта. Указатель на переменную или базовый класс 
превращается в мусор. Проблема обеспечения согласованности в такой неразберихе не решается за 
обедом в течение одного дня. Усиленная формулировка (указываемые объекты должны существовать 
до тех пор, пока для них существуют грани) откладывается до той части книги, которая посвящена 
управлению памятью. Слабая формулировка легко обеспечивается с помощью ведущих указателей. 
Если грань работает с объектом через ведущий указатель, то у ведущего указателя можно спросить: «А 
указываешь ли ты сейчас на существующий объект?» Если ответ будет отрицательным, оператор 
!
возвращает 
true
, и функции начинают инициировать исключения. Правда, остается другая проблема 
— когда и как удалять ведущие указатели. Ее также лучше рассматривать при обсуждении различных 
стратегий управления памятью. 
Грани и ведущие указатели 
Концепции граней и кристаллов хорошо сочетаются с концепцией ведущих указателей. Существуют 
два основных подхода. 
Ведущий указатель в середине 
Традиционный ведущий указатель (вероятно, с использованием оператора 
->
) вставляется между 
указываемым объектом и гранью. В этом случае грани превращаются в разновидность дескрипторов, 
косвенно обращающихся к членам указываемого объекта через ведущий указатель. Ведущий указатель 
должен уметь хотя бы генерировать кристалл, который затем будет использоваться клиентами для 
генерации других граней. Если весь доступ к объекту осуществляется через грани, подумайте о том, 
чтобы сделать оператор 
->
ведущего указателя закрытым, а грани объявить друзьями. 
Превращение кристалла в ведущий указатель 
Кристаллу присваиваются функции ведущего указателя. Затем кристалл генерирует грани и 
поддерживает семантику ведущего указателя для конструирования и уничтожения. Грани получают 
доступ к указываемому объекту через кристалл. Чтобы вам было удобнее, можно предоставить 
закрытый оператор 
->
в кристалле и сделать грани друзьями кристалла. Грани фактически 
превращаются в дескрипторы и получают доступ к указываемому объекту косвенно, через кристалл. 

---

 106 
Переходные типы 
Основная идея переходного типа (malleable type) - класс, экземпляры которого как бы изменяют свой 
тип во время выполнения программы. Конечно, формально 
В 
C++ такого происходить не может — 
иначе вам пришлось бы всерьез и надолго подружиться с отладчиком. Тем не менее, чудеса 
современных указателей позволяют добиться почти того же эффекта. 
Полиморфные указываемые объекты 
В базовом варианте ведущего указателя присутствует переменная с типом 
Pointee*
. Нo кто сказал, 
что объект, на который она ссылается, должен быть настоящим 
Pointee
, а не каким-нибудь классом, 
производным от 
Pointee
? 
// В файле Foo.h 
class Foo { 
protected: 
Foo(); 
public: 
// 
Члены Foo 
}; 
class Pfoo { // Ведущий указатель 
private: 
Foo* 
foo; 
public: 
PFoo(); 
Foo* operator->() const { return foo; } 
// 
Остальные члены, характерные для ведущих указателей 
}; 
// В файле Foo.cpp 
class DerivedFromFoo : public Foo { 
private: 
// 
Закрытые члены производного класса 
public: 
DerivedFromFoo(); 
// 
Функция открытая, но спрятанная в файле .cpp 
// 
Переопределения функций класса Foo 
}; 
PFoo::PFoo() : foo(new DrivedFromFoo) 
{ 
} 
Ловкость рук и никакого мошенничества! Ведущий указатель подсунул вместо 
Foo
нечто совершенно 
иное, а клиенты ничего не замечают. Ага! Теперь вы понимаете, почему конструктор 
Foo
объявлялся 
защищенным, а не закрытым! Класс 
PFoo
уже можно не объявлять другом; доступ к конструкторам 
Foo
нужен только конструктору 
DerivedFromFoo
. 
В части 3 мы поговорим о том, какое наследование нужно, чтобы эта схема работала (а именно, чтобы 
все классы, производные от 
Foo
, имели тот же открытый интерфейс, что и сам 
Foo
). А пока продолжим 
изучение указателей и всего, что с ними связано. 

---