Smart pointers для начинающих

в 5:13, , рубрики: c++, memory leaks, smart pointers, Программирование, умные указатели, управление памятью, метки: , , , ,

Эта небольшая статья в первую очередь предназначена для начинающих C++ программистов, которые либо слышали об умных указателях, но боялись их применять, либо они устали следить за new-delete.
Итак, программисты С++ знают, что память нужно освобождать. Желательно всегда. И они знают, что если где-то пишется new, обязательно должен быть соответствующий delete. Но ручные манипуляции с памятью могут быть чреваты, например, следующими ошибками:

  • утечки памяти;
  • разыменовывание нулевого указателя, либо обращение к неициализированной области памяти;
  • удаление уже удаленного объекта;

Утечка в принципе не так критична, если программа не работает 24/7, либо код, ее вызывающий, не находится в цикле. При разыменовывании нулевого указателя мы гарантированно получим сегфолт, осталось только найти тот случай когда он становится нулевым (вы же понимаете о чем я). При повторном удалении может случиться вообще все, что угодно. Обычно (хотя может быть и не всегда), если вам выделяется блок памяти, то где-то с ним по соседству лежит значение, определяющее количество выделенной памяти. Детали зависят от реализациии, но допустим, что вы выделили 1 кб памяти начиная с некоторого адреса. Тогда по предыдущему адресу будет храниться число 1024, таким образом станет возможным при вызове delete удалить ровно 1024 байт памяти, не больше и не меньше. При первом вызове delete все отлично, при втором вы потрете не те данные. Чтобы всего этого избежать, либо уменьшить вероятность появления подобного рода ошибок, и были придуманы умные указатели.

Введение

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

  1. class VideoBuffer {
  2.     int *myPixels;
  3. public:
  4.     VideoBuffer() {
  5.         pixels = new int[640 * 480];
  6.     }
  7.     void makeFrame() { /* работаем с растром */ }
  8.     ~VideoBuffer() {
  9.         delete [] pixels;
  10.     }
  11. };
  12. int game() {
  13.     VideoBuffer screen;
  14.     screen.makeFrame();
  15. }

* This source code was highlighted with Source Code Highlighter.

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

  1. int game() {
  2.     int *myPixels = new int[640 * 480];
  3.     // работаем
  4.     delete [] pixels;
  5. }

* This source code was highlighted with Source Code Highlighter.

В принципе, никакой разницы, но представим себе такой код:

  1. int game() {
  2.     int *myPixels = new int[640 * 480];
  3.     // работаем
  4.     if (someCondition)
  5.         return 1;        
  6.     // работаем дальше    
  7.     if (someCondition)
  8.         return 4;        
  9.     // поработали
  10.     delete [] pixels;
  11. }

* This source code was highlighted with Source Code Highlighter.

Придется в каждой ветке выхода из функции писать delete [], либо вызывать какие-либо дополнительные функции деинициализации. А если выделений памяти много, либо они происходят в разных частях функции? Уследить за всем этим будет все сложнее и сложнее. Подобная ситуация возникает, если мы в середине функции бросаем исключение: гарантируется, что объекты на стеке будут уничтожены, но с кучей проблема остается открытой.
Ок, будем использовать RAII, в конструкторах инициализировать память, в деструкторе освобождать. И пусть поля нашего класса будут указателями на участки динамической памяти:

  1. class Foo {
  2.     int *data1;
  3.     double *data2;
  4.     char *data3;
  5. public:
  6.     Foo() {
  7.         data1 = new int(5);
  8.         ...
  9.     }
  10.     ~Foo() {
  11.         delete data1;
  12.         ...
  13.     }
  14. }

* This source code was highlighted with Source Code Highlighter.

Теперь представьте, что полей не 3, а 30, а значит в деструкторе придется для всех них вызывать delete. А если мы второпях добавим новое поле, но забудем его убить в деструкторе, то последствия будут негативными. В итоге получается класс, нагруженный операциями выделенияосвобождения памяти, да еще и непонятно, все ли было правильно удалено.
Поэтому предлагается использовать умные указатели: это объекты, которые хранят указатели на динамически аллоцированные участки памяти произвольного типа. Причем они автоматически очищают память по выходу из области видимости.
Сначала рассмотрим то, как они выглядят в С++, затем перейдем к обзору некоторых распространенных типов умных указателей.

Простейший smart pointer

  1. // Класс нашего умного указателя
  2. template <typename T>
  3. class smart_pointer {
  4.     T *m_obj;
  5. public:
  6.     // Отдаем ему во владение некий объект
  7.     smart_pointer(T *obj)
  8.         : m_obj(obj)
  9.     { }
  10.     // По выходу из области видимости этот объект мы уничтожим
  11.     ~smart_pointer() {
  12.         delete m_obj;
  13.     }
  14.     // Перегруженные операторы
  15.     // Селектор. Позволяет обращаться к данным типа T посредством "стрелочки"
  16.     T* operator->() { return m_obj; }
  17.     // С помощью такого оператора мы можем разыменовать указатель и получить ссылку на
  18.     // объект, который он хранит
  19.     T& operator* () { return *m_obj; }
  20. }
  21. int test {
  22.     // Отдаем myClass во владение умному указателю
  23.     smart_pointer<MyClass> pMyClass(new MyClass(/*params*/);    
  24.     // Обращаемся к методу класса MyClass посредством селектора
  25.     pMyClass->something();    
  26.     // Допустим, что для нашего класса есть функция вывода его в ostream
  27.     // Эта функция одним из параметров обычно получает ссылку на объект,
  28.     // который должен быть выведен на экран
  29.     std::cout << *pMyClass << std::endl;    
  30.     // по выходу из скоупа объект MyClass будет удален
  31. }

* This source code was highlighted with Source Code Highlighter.

Понятно, что наш смарт пойнтер не лишен недостатков (например, как хранить в нем массив?), но он в полной мере реализует идиому RAII. Он ведет себя так же, как и обычный указатель (благодаря перегруженным операторам), причем нам не нужно заботиться об освобождении памяти: все будет сделано автоматически. По желанию к перегруженным операторам можно добавить const, гарантировав неизменность данных, на которые ссылается указатель.
Теперь, если вы поняли, что получаете определенные преимущества, при использовании таких указателей, рассмотрим их конкретные реализации. Если вам не нравится эта идея, то все равно, попробуйте использовать их в какой-нибудь своей маленькой программке, уверяю, вам должно понравиться.
Итак, наши смарт-пойнтеры:

  • boost::scoped_ptr
  • std::auto_ptr
  • std::tr1::shared_ptr (он же std::shared_ptr в C++11, либо boost::shared_ptr из boost)

boost::scoped_ptr

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

  1. #include <boost/scoped_ptr.hpp>
  2. int test() {
  3.     boost::scoped_ptr<int> p1(new int(6));
  4.     boost::scoped_ptr<int> p2(new int(1));    
  5.     p1 = p2; // Нельзя!
  6. }

* This source code was highlighted with Source Code Highlighter.

Оно и понятно, если бы было разрешено присваивание, то и p1 и p2 будут указывать на одну и ту же область памяти. А по выходу из функции оба удалятся. Что будет? Никто не знает. Соответственно, этот пойнтер нельзя передавать и в функции.
Тогда зачем он нужен? Советую применять его как указатель-обертка для каких-либо данных, которые выделяются динамически в начале функции и удаляются в конце, чтобы избавить себя от головной боли по поводу корректной очистки ресурсов.
Подробное описание здесь.

std::auto_ptr

Чуть-чуть улучшенный вариант предыдущего, к тому же он есть в стандартной библиотеке (хотя в C++11 вроде как deprecated). У него есть оператор присваивания и конструктор-копировщик, но работают они несколько необычно.
Поясняю:

  1. #include <memory>
  2. int test() {
  3.     std::auto_ptr<MyObject> p1(new MyObject);
  4.     std::auto_ptr<MyObject> p2;    
  5.     p2 = p1;
  6. }

* This source code was highlighted with Source Code Highlighter.

Теперь при присваивании в p2 будет лежать указатель на MyObject (который мы создавали для p1), а в p1 не будет ничего. То есть p1 теперь обнулен. Это так называемая семантика перемещения. Кстати, оператор копирования поступает таким же образом.
Зачем это нужно? Ну например у вас есть функция, которая должна создавать какой-то объект:

  1. std::auto_ptr<MyObject> giveMeMyObject();

* This source code was highlighted with Source Code Highlighter.

Это означает, что функция создает новый объект типа MyObject и отдает его вам в распоряжение. Понятней станет, если эта функция сама является членом класса (допустим Factory): вы уверены, что этот класс (Factory) не хранит в себе еще один указатель на новый объект. Объект ваш и указатель на него один.
В силу такой необычной семантики auto_ptr нельзя использовать в контейнерах STL. Но у нас есть shared_ptr.

std::shared_ptr (С++11)

Умный указатель с подсчетом ссылок. Что это значит. Это значит, что где-то есть некая переменная, которая хранит количество указателей, которые ссылаются на объект. Если эта переменная становится равной нулю, то объект уничтожается. Счетчик инкрементируется при каждом вызове либо оператора копирования либо оператора присваивания. Так же у shared_ptr есть оператор приведения к bool, что в итоге дает нам привычный синтаксис указателей, не заботясь об освобождении памяти.

  1. #include <memory> // либо <tr1/memory> для компиляторов, еще не поддерживающих C++11
  2. #include <iostream>
  3. int test() {
  4.     std::shared_ptr<MyObject> p1(new MyObject);
  5.     std::shared_ptr<MyObject> p2;    
  6.     p2 = p1;    
  7.     if (p2)
  8.         std::cout << "Hello, world!n";
  9. }

* This source code was highlighted with Source Code Highlighter.

Теперь и p2 и p1 указывают на один объект, а счетчик ссылок равен 2, По выходу из скоупа счетчик обнуляется, и объект уничтожается. Мы можем передавать этот указатель в функцию:

  1. int test(std::shared_ptr<MyObject> p1) {
  2.     // делаем что-то
  3. }

* This source code was highlighted with Source Code Highlighter.

Заметьте, если вы передаете указатель по ссылке, то счетчик не будет увеличен. Вы должны быть уверены, что объект MyObject будет жив, пока будет выполняться функция test.

Итак, smart pointers это хорошо, но есть и минусы.
Во-первых это небольшой оверхед, но я думаю у вас найдется несколько тактов процессора ради такого удобства.
Во-вторых это boiler-plate, например

  1. std::tr1::shared_ptr<MyNamespace::Object> ptr = std::tr1::shared_ptr<MyNamespace::Object>(new MyNamespace::Object(param1, param2, param3))

* This source code was highlighted with Source Code Highlighter.

Это частично можно решить при помощи дефайнов, допустим:

  1. #define sptr(T) std::tr1::shared_ptr<T>

* This source code was highlighted with Source Code Highlighter.

Либо при помощи typedef.
В-третьих, существует проблема циклических ссылок. Рассматривать ее здесь не буду, чтобы не увеличивать статью. Так же остались нерассмотренными boost::weak_ptr, boost::intrusive_ptr и указатели для массивов.
Кстати, smart pointers достаточно хорошо описаны у Джеффа Элджера в книге «С++ for real programmers».

Автор: flamingo

* - обязательные к заполнению поля

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js