unique_ptr с API, который ожидает сырые указатели? - PullRequest
3 голосов
/ 28 марта 2012

После примерно 10 лет использования управляемой памяти и функциональных языков я наконец-то вернулся домой на C ++, и умные указатели выводят меня из себя.Половина документации по-прежнему относится к устаревшей auto_ptr.

Я пытаюсь реализовать эту довольно простую программу Bullet "hello world" :

int _tmain(int argc, _TCHAR* argv[])
{
    auto bp = unique_ptr<btBroadphaseInterface>(new btDbvtBroadphase);
    auto cc = unique_ptr<btDefaultCollisionConfiguration>(new btDefaultCollisionConfiguration);
    auto disp = unique_ptr<btDispatcher>(new btCollisionDispatcher(cc));
}

Конструктор btCollisionDispatcher хочет btCollisionConfiguration*, но вместо этого я даю ему unique_ptr.

Что я обычно хочу делать в этом случае?Если есть способ «де-умного» указателя, что-то подсказывает мне, что unique_ptr не является правильным умным указателем для использования.

enter image description here

C ++ был моим языкомвыбор, прежде чем я перешел к другим вещам.Это немного шокирует, когда я возвращаюсь и вижу, что все модели и практики полностью изменились.

Ответы [ 2 ]

14 голосов
/ 28 марта 2012

Существует функция-член get(), которая выдает необработанный указатель, удерживаемый unique_ptr.Это не приводит к тому, что unique_ptr отказывается от владения, поэтому надлежащая очистка все равно будет происходить (осторожно с сохранением этого необработанного указателя!).

Существует также функция-член release(), которая отменяет владение,Это означает, что вы вернулись на землю тупого указателя, и вся ответственность за очистку лежит на вас.

Я не могу понять, почему код использует new, а не , просто используя автоматическое хранениеобъекты , но я собираюсь притвориться, что есть причина ...

3 голосов
/ 28 марта 2012

Функция-член get возвращает нижний указатель и может использоваться с существующим кодом, если этот код не управляет передаваемой вами памятью.

...