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

 
83 
Если оба предположения верны, для хранения обоих адресов можно использовать одну переменную 
класса. Если младший бит установлен (то есть если «адрес» четный), остальные 31 бит определяют 
дисковый адрес. Когда младший бит сброшен, все 32 бита определяют адрес памяти. Если вам 
потребуется не только считывание, но и запись, объекту лучше знать свой собственный дисковый 
адрес, поскольку адрес, хранящийся в указателе, при считывании портится. 
За дымовой завесой кэширующих указателей прячется интересная концепция: умные указатели могут 
использоваться как общее средство для доступа к объектам независимо от того, где находится объект 
и существует ли он вообще. Углубляясь в джунгли C++, мы будем рассматривать эту концепцию под 
разными углами, пока она не превратится в один из принципов Дао, о которых я упоминал во 
вступительной главе. 

---

---

Ведущие 
указатели и 
дескрипторы
После совсем непродолжительного знакомства с умными указателями мы успели наткнуться на целый 
ряд фундаментальных проблем. Многие из них связаны с тем фактом, что на один объект может 
ссылаться любое количество умных указателей. Как в этом случае узнать, когда можно удалить 
объект? Кто ведет статистику использования объекта и обращается к ней при необходимости (если вам 
вдруг понадобится такая возможность)? Кто создает объект? Что означает присваивание одного умного 
указателя другому? Заиграет ли наконец в этом сезоне наша любимая команда или она снова разобьет 
наши сердца? Ниже вы найдете ответы на эти и многие другие интригующие вопросы. 
Семантика ведущих указателей 
При работе с умными указателями имеется один важный частный случай — когда два умных указателя 
не должны одновременно ссылаться на один объект. Между указателем и объектом, на который он 
ссылается, существует однозначное соответствие (за исключением особого случая умных указателей, 
ссылающихся на 
NULL
). Если в программном дизайне действует такое ограничение, говорят, что 
реализуется семантика ведущих указателей (master pointers). 
Конечно, можно просто объявить через местную газету, что указатели должны использоваться таким и 
только таким образом. А можно защитить ваших пользователей от самих себя и подкрепить 
семантические правила языковыми средствами C++. Если вы мудро выберете второй вариант, придется 
учесть следующее: 
1. Указываемые объекты должны создаваться указателями в конструкторах. 
2. Деструктор указателя должен удалять указываемый объект. 
3. Конструктор копий должен создавать точную копию указываемого объекта. 
4. Оператор присваивания 
operator=
должен удалять текущий указываемый объект, 
находящийся слева от него, и заменять его копией указываемого объекта справа. 
Кроме того, было бы разумно сделать еще две вещи: 
5. Ограничить доступ к конструкторам класса указываемого объекта. 
6. Создавать указатели с помощью производящих функций (factory functions). 
Обе рекомендации будут подробно рассмотрены в последующих разделах. Прототип ведущего 
указателя, который мы собираемся воплотить, выглядит так: 
template  
class MP { 
private: 
Type* 
t; 
public: