Использование "умных" указателей

class A {  
public: void method(); 
}; 

class APtr { 
protected: A* a; 
public: APtr(); 
~APtr(); 
A* operator->(); 
};   

inline APtr::APtr() : a(new A) { }   
inline APtr::~APtr() { delete a; }   
inline A* APtr::operator->() { return a; } 

aptr->method();

Тонкости того, почему operator->() возвращает именно указатель A* (у которого есть свой селектор), а не, например, ссылку A& и все равно все компилируется таким образом, что выполнение доходит до метода A::method(), я пропущу за ненадобностью --- я не собираюсь рассказывать о том, как работает этот механизм и какие приемы применяются при его использовании --- это очень подробно написано в книге Джеффа Элджера "C++ for real programmers" (комментарий к этой замечательной книге обязательно появится в соответствующем разделе моей странички), в которой вообще буквально половина книги посвящена "умным" указателям.

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

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

Вторая ошибка может дать самое большое количество неприятностей. Все дело в том, что, хотя на первый взгляд она ничем особенным не отличается от первой, тем не менее на практике повторное удаление объекта приводит к тому, что менеджер кучи удаляет что-то совсем невообразимое. Вообще, что значит "удаляет"? Это значит, что помечает память как пустую (готовую к использованию). Обычно, менеджер кучи, для того что бы знать, сколько памяти удалить, в блок выделяемой памяти вставляет его размер. Так вот, если память уже была занята чем-то другим, то по "неверному" указателю находится неправильное значение размера блока, таким образом менеджер кучи удалит некоторый случайный размер используемой памяти. Это даст следующее: при следующих выделениях памяти (рано или поздно) менеджер кучи отдаст эту "неиспользуемую" память под другой запрос и... на одном клочке пространства будут ютиться два разных объекта. Крах программы произойдет почти обязательно, это лучшее что может случится. Значительно хуже, если программа останется работать и будет выдавать правдоподобные результаты. Одна из самых оригинальных ошибок, с которой я столкнулся и которая, скорее всего, была вызвана именно повторным удалением одного и того же указателя, было то, что программа, работающая несколько часов, рано или поздно "падала" в... функции malloc(). Причем проработать она должна была именно несколько часов, иначе эта ситуация не повторялась.

Таким образом, автоматическое удаление при гарантированном неиспользовании указателя, это явный плюс. В принципе, можно позавидовать программистам на Java, у которых подобных проблем не возникает; зато, у них возникают другие проблемы ;) 

Я еще не убедил вас в полезности использования "умных" указателей? Странно. Тогда я приведу примеры реального использования в своих проектах. Вот, например, объявление того самого "умного" указателя с подсчетом ссылок, о котором я говорил: 

template<class T>

class MPtr

{

public:

MPtr();

MPtr(const MPtr<T>& p);

~MPtr();

MPtr(T* p);

T* operator->() const;

operator T*() const;

MPtr<T>& operator=(const MPtr<T>& p);

protected:

struct RealPtr

{

T* pointer;

unsigned int count;

RealPtr(T* p = 0);

~RealPtr();

};

RealPtr* pointer;

private:

};