use_count
сообщает, сколько экземпляров типа shared_ptr
в данный момент указывают на наш объект:
void weak_ptr_info(const weak_ptr&p)
{
cout << "---------" << boolalpha
<< "\nexpired: " << p.expired()
<< "\nuse_count: " << p.use_count()
<< "\ncontent: ";
4. При желании получить доступ к самому объекту нужно вызвать функцию
lock
. Она возвращает общий указатель на объект. Если объект больше не существует, то полученный общий указатель, по сути, является null
. Следует это проверять, прежде чем получать доступ к объекту.
if (const auto sp (p.lock()); sp) {
cout << sp->value << '\n';
} else {
cout << "\n";
}
}
5. Создадим пустой слабый указатель в функции
main
и выведем на экран его содержимое, оно, конечно, поначалу будет пустым:
int main()
{
weak_ptr weak_foo;
weak_ptr_info(weak_foo);
6. В новой области видимости создадим новый общий указатель, содержащий только что созданный экземпляр класса
Foo
. Затем скопируем его в слабый указатель. Обратите внимание: это не увеличит счетчик ссылок общего указателя. Счетчик ссылок будет иметь значение 1
, поскольку им владеет только один общий указатель.
{
auto shared_foo (make_shared(1337));
weak_foo = shared_foo;
7. Вызовем функцию слабого указателя прежде, чем покинем область видимости, и снова после этого. Экземпляр типа
Foo
должен быть мгновенно уничтожен, несмотря на то что на него указывает слабый указатель.
weak_ptr_info(weak_foo);
}
weak_ptr_info(weak_foo);
}
8. Компиляция и запуск программы дадут три результата работы функции
weak_ptr_info
. В первом вызове слабый указатель пуст. Во втором он уже указывает на созданный нами экземпляр типа Foo
и может разыменовать его после блокировки. Перед третьим вызовом мы покидаем внутреннюю область видимости, что заставляет сработать деструктор экземпляра типа Foo
в соответствии с нашими ожиданиями. После этого мы не можем получить содержимое экземпляра типа Foo
с помощью слабого указателя, а сам слабый указатель корректно распознает, что срок его действия истек.
$ ./weak_ptr
---------
expired: true
use_count: 0
content:
---------
use_count: 1
expired: false
content: 1337
DTOR Foo 1337
---------
use_count: 0
content:
expired: true
Как это работает
Слабые указатели предоставляют способ указать на объект, поддерживаемый общими указателями, не увеличивая его счетчик использования. Да, необработанный указатель способен сделать то же самое, но не может сказать, является ли он висящим. Слабый указатель лишен этого недостатка!
Чтобы понять, как слабые указатели работают с общими, сразу рассмотрим рис. 8.3.
Принцип работы аналогичен тому, что приведен на рис. 8.2. В шаге 1 у нас имеются два общих указателя и слабый, указывающие на объект типа
Foo
. Несмотря на то что на него указывают три объекта, его счетчик использования изменяют только общие указатели, именно поэтому его значение равно 2
. Слабый указатель изменяет только слабый счетчик блока управления. В шагах 2 и 3 экземпляры общих указателей уничтожаются, это снижает значение счетчика использования до 0
. В шаге 4 это приводит к тому, что объект Foo
удаляется, но блок управления остается. Слабому указателю все еще нужен блок управления, чтобы определить, является ли он висящим. Блок управления удаляется только в тот момент, когда последний слабый указатель, указывающий на него, тоже выходит из области видимости.Мы также можем сказать, что срок действия висящего слабого указателя истек. Для проверки этого состояния можно опросить метод
expired
класса weak_ptr
, он вернет булево значение. Если оно равно true
, то мы не можем разыменовать слабый указатель, поскольку он не указывает на объект.Чтобы разыменовать слабый указатель, нужно вызвать метод
lock()
. Это удобно и безопасно, поскольку данная функция возвращает общий указатель. Пока мы его храним, объект, на который он указывает, не может пропасть, поскольку мы увеличили его счетчик использования путем блокировки. Если объект удаляется вскоре после вызова lock()
, то общий указатель, по сути, является null
.Упрощаем управление ресурсами устаревших API с применением умных указателей
Умные указатели (
unique_ptr
, shared_ptr
и weak_ptr
) очень полезны, и можно сказать, что программист должен всегда использовать их вместо выделения и освобождения памяти вручную.Но если для объекта нельзя выделить память с помощью оператора
new
и/или освободить память, задействуя оператор delete
? Во многих устаревших библиотеках есть собственные функции выделения/удаления памяти. Кажется, это может стать проблемой, поскольку мы узнали, что умные указатели полагаются на операторы new
и delete
. Если создание и/или разрушение конкретных типов объектов полагается на конкретные интерфейсы удаления фабричных функций, не помешает ли это получить огромное преимущество от использования умных указателей?Вовсе нет. В этом разделе мы увидим, что нужно лишь немного изменить умные указатели, чтобы позволить им следовать определенным процедурам выделения и удаления памяти для конкретных объектов.
Как это делается
В данном примере мы определим тип, для которого нельзя непосредственно выделить память с помощью оператора new и нельзя освободить ее, прибегнув к оператору
delete
. Поскольку это помешает использовать его вместе с умными указателями, мы внесем небольшие изменения в экземпляры классов unique_ptr
и smart_ptr
.
1. Как и всегда, сначала включим необходимые заголовочные файлы и объявим об использовании пространства имен
std
по умолчанию:
#include
#include
#include
using namespace std;
2. Далее объявим класс, конструктор и деструктор которого имеют модификатор
private
. Таким образом, симулируем проблему, когда нужно получать доступ к конкретным функциям, чтобы создавать и удалять экземпляры этого класса.
class Foo
{
string name;
Foo(string n)
: name{n}
{ cout << "CTOR " << name << '\n'; }
~Foo() { cout << "DTOR " << name << '\n';}
3. Статические методы
create_foo
и destroy_foo
будут создавать и удалять экземпляры типа Fo
o. Они работают с необработанными указателями. Это симулирует ситуацию, возникающую при использовании устаревшего API языка С, который не дает задействовать их непосредственно для обычных указателей