В каких случаях возникает потребность использования raw pointers в современном C++?
1,00
р.
После появления новых возможностей в C++ таких как std::make_shared() и std::make_unique то возникает вопрос : А есть ли хоть один случай, когда действительно нужно работать с сырым указателем?
В этом вопросе я не учитываю случаи, когда стороняя библиотека в каком-либо из методов принимает указатель.
Я беру среднего по уровню программиста на C++. Он пишет свою библиотеку без использования сторонего кода. И у меня не находится ни одного примера, когда ему действительно нужно пользоваться сырыми указателями.
Ответ
Во внутренних деталях реализации, когда владеющие указатели усложняют взаимодействие, когда нужно разделять владение, но время жизни объекта чётко детерминировано и не возникает вопроса: где и когда чистить объект (shared_ptr в таких случаях - лишнее), когда ссылкой не обойтись, потому как возможна ситуация с nullptr у объекта. В публичных API стараться избегать, пока это возможно, либо чётко обосновывать - "почему?" и "зачем?".
В общем, я придерживаюсь правила: обходиться без сырых указателей, пока это возможно. Пока не подводило (embedded).
Кстати, возможно забавно, но в C проектах, при достижении определённого уровня сложности, тоже начинают появляются механизмы разделяемого владения. Это всем известные xxx_ref(object)/xxx_unref(object). Примеры: GLib со своим gobject, FFmpeg активно внедряет подсчёт ссылок для AVPacket и AVFrame (для таких случаев в Boost существует intrusive_ptr), ядро Linux тоже не стоит в стороне (https://lwn.net/Articles/336224/ по слову Reference Counting или http://www.makelinux.net/books/lkd2/ch17lev1sec7) со своим kobject.
В этом вопросе я не учитываю случаи, когда стороняя библиотека в каком-либо из методов принимает указатель.
Я беру среднего по уровню программиста на C++. Он пишет свою библиотеку без использования сторонего кода. И у меня не находится ни одного примера, когда ему действительно нужно пользоваться сырыми указателями.
Ответ
Во внутренних деталях реализации, когда владеющие указатели усложняют взаимодействие, когда нужно разделять владение, но время жизни объекта чётко детерминировано и не возникает вопроса: где и когда чистить объект (shared_ptr в таких случаях - лишнее), когда ссылкой не обойтись, потому как возможна ситуация с nullptr у объекта. В публичных API стараться избегать, пока это возможно, либо чётко обосновывать - "почему?" и "зачем?".
В общем, я придерживаюсь правила: обходиться без сырых указателей, пока это возможно. Пока не подводило (embedded).
Кстати, возможно забавно, но в C проектах, при достижении определённого уровня сложности, тоже начинают появляются механизмы разделяемого владения. Это всем известные xxx_ref(object)/xxx_unref(object). Примеры: GLib со своим gobject, FFmpeg активно внедряет подсчёт ссылок для AVPacket и AVFrame (для таких случаев в Boost существует intrusive_ptr), ядро Linux тоже не стоит в стороне (https://lwn.net/Articles/336224/ по слову Reference Counting или http://www.makelinux.net/books/lkd2/ch17lev1sec7) со своим kobject.
