В настоящее время я использую некоторые функции из библиотеки glib. С glib также появляется gio. glib - это библиотека C, поэтому мне нужно удалить некоторые структуры, которые я создаю.
для многих объектов я создаю smartpointer, например:
std::shared_ptr<GAsyncQueue> my_queue = std::shared_ptr<GAsyncQueue>(g_async_queue_create(), g_async_queue_unref);
Для этого создается общий указатель на GAsyncQueue, и это безопасно уничтожает очередь в конце ее жизни.
Однако я сталкиваюсь с проблемой, когда получаю указатель из библиотеки gio, который я не должен освобождать. В следующем коде my_connection есть GSocketClient, который реализует (в glib-talk) GIOStream.
std::shared_ptr<GInputStream> my_input_stream =
std::shared_ptr<GInputStream> (
g_io_stream_get_input_stream(G_IO_STREAM(my_connection.get()))
);
Поскольку в документации по GIOStream упоминается, что указатель, полученный с помощью g_io_stream_get_input_stream(), не должен быть освобожден. Это связано с тем, что он принадлежит экземпляру my_connection.
Я думал о создании lamda для объекта destroy, второго параметра объекта общего указателя. например auto deleter = [](GInputStream* ptr) {};, а затем дать эту лямбду как функцию detroy для общего указателя, но это кажется глупым.
Ну, альтернатива no-op deleter может использовать общий указатель наложения aliasing
template <class U> shared_ptr (const shared_ptr<U>& x, element_type* p) noexcept;
Он разделяет x, но после get() вы вернетесь p.
Обсуждение: Что такое конструктор псевдонимов shared_ptr для?
Вероятно, вам просто не нужен std::shared_ptr. И вам, вероятно, даже не нужен указатель.
Когда я прочитал ваш вопрос и комментарии, я не вижу смысла против
auto& my_input_stream = *( g_io_stream_get_input_stream(G_IO_STREAM(my_connection.get())) )
Верно, что указатели допускают дополнительные данные. Однако также верно, что он в основном использовался неправильно. Имея
void foo( type* ptr)
{
if (!ptr)
throw exception;
}
часто не имеет смысла. Если функция должна работать над конкретными данными, разрешение параметра NULL полезно, только если вы беспокоитесь о предоставлении этих данных. В противном случае просто требуется ссылка (возможно, const) на объект.
Умные указатели полезны; но они все еще указатели. Избежать их вообще, если это возможно, еще лучше.
Из комментариев:
Однако ссылка всегда должна быть инициализирована
Совершенно верно. Начиная с С++ 11, хотя у нас есть std::reference_wrapper, который также может быть повторно закреплен и сохранен в контейнерах.
Вы можете использовать тип удаления, который ничего не делает, но его необходимо передать как аргумент конструктору shared_ptr
struct DoNothing {
template <typename T>
void operator()(T*) const noexcept { }
};
При создании shared_ptr вам нужно будет создать один из этих удалений и передать его в конструкторе (как вы это делаете с лямбдой). Вы можете сделать это проще на себе с помощью промежуточной функции
template <typename T>
std::shared_ptr<T> non_deleting_shared_ptr(T* ptr) {
return {ptr, DoNothing};
}
auto my_input_stream =
non_deleting_shared_ptr(
g_io_stream_get_input_stream(G_IO_STREAM(my_connection.get()));
Однако главный вопрос заключается в том, почему вы используете интеллектуальные указатели, когда вы не хотите, чтобы принадлежность к нему была частью. Вам почти наверняка будет лучше всего с GAsyncQueue*, если, конечно, вы не находитесь в ситуации, когда у вас есть shared_ptr, который иногда нужно освобождать. Как член данных, возможно?