Блог

Я изучал интеллектуальные указатели, которые являются частью C 0x, и столкнулся с чем-то, что мне кажется непоследовательным. В частности, как обрабатывается политика уничтожения unique_ptr<> и shared_ptr<>.

Для unique_ptr<> вы можете специализировать std::default_delete<> и с этого момента, если вы явно не запросите другую политику уничтожения, будет использоваться новое значение по умолчанию.

Рассмотрим следующее:

 struct some_c_type;

some_c_type *construct_some_c_type();
void destruct_some_c_type(some_c_type *);

namespace std  {
    template <> struct default_delete<some_c_type> {
        void operator()(some_c_type *ptr) {
            destruct_some_c_type(ptr);
        }
     };
}
  

Теперь, когда это установлено, unique_ptr<> по умолчанию будет использовать соответствующую политику уничтожения:

 // Because of the specialization, this will use destruct_some_c_type
std::unique_ptr<some_c_type> var(construct_some_c_type());
  

Теперь сравните это с shared_ptr<>. С помощью shared_ptr<> вам необходимо явно запросить соответствующую политику уничтожения, иначе по умолчанию используется operator delete:

 // error, will use operator delete 
std::shared_ptr<some_c_type> var(construct_some_c_type());

// correct, must explicitly request the destruction policy
std::shared_ptr<some_c_type> var(construct_some_c_type(),
                                 std::default_delete<some_c_type>());
  

Два вопроса.

1. Правильно ли я понимаю, что shared_ptr<> требует указания политики уничтожения каждый раз, когда она используется, или я что-то упускаю?
2. Если я ничего не упускаю, есть идеи, почему эти два отличаются?

P.S. Причина, по которой меня это волнует, заключается в том, что моя компания много занимается смешанным программированием на C и C . Коду C часто приходится использовать объекты в стиле C, поэтому для меня очень важна простота указания другой политики уничтожения по умолчанию.

Я думаю, вопрос сводится к тому, почему std::shared_ptr не может иметь связанного deleter (в этом случае он просто вызывает delete ) вместо того, чтобы создавать std::default_delete по умолчанию. (Понятия не имею. Если бы это было предназначено default_delete для специализации, можно было бы ожидать, что оно будет использоваться shared_ptr .)

В противном случае возможны компромиссы.

Лучше иметь меньше аргументов шаблона. В ссылке Boost упоминается, что это позволяет фабрике изменять схему распределения, не затрагивая пользователя фабрики.

unique_ptr С другой стороны, предполагается, что A должен быть очень легким. Как бы вы сохранили средство удаления с нулевыми затратами пространства (в случае функтора без членов), если бы оно не было частью типа (GCC использует tuple, где объекты без членов не занимают места в памяти)?

Субъективно, я думаю, я бы предпочел:

 unique_ptr<FILE, FCloser> f(fopen(x, y));
  

Для

 unique_ptr<FILE> f(fopen(x, y)); //default_delete<FILE> has been specialized
  

В первом случае нечего гадать. Если ресурс получен не из new или new[] , удаление должно быть задано явно.