Это не то, что я описывал, см. выше

Сырые указатели

Если я пишу свой list, стоит ли в нем использовать умные указатели?

Уже не надо?)

Ну можно в типе листа юники хранить, если реализация не кольцевая

В нодах умные не нужны

А чем шареды не подходят?

У ноды один владелец

То же самое можно устроить в two-phase для dependent вызова функции.

Это дерево(родительская нода). В случае юников, когда оно разрушается, разрушится и нода. Работают с ней разные другие объекты. Тогда они через сырые должны работать? Или забирать себе владение, а потом возвращать?

Здравствуйте. Пишу сюда, поскольку найти данную инфу в гугле не вышло. Вопрос. Я хочу использовать в проекте контейнера, которые предоставляет boost. (boost::container::stable_vector, boost::container::static_vector и другие). Но столкнулся с тем, что нет возможности в gdb нормально видеть что именно лежит в этих контейнерах. (там вроде как используется void*). А в ином случае будет трудным процес отладки проекта. Единственное что удалось найти это BoostPrettyPrinter на гитхабе, но он покрывает только маленькую часть библиотеки контейнеров буста и не работает с теми контейнерами которые нужны мне. Так вот вопрос: если возможность сделать так чтобы процес отладки при использовании контейнеров буста был не таким адским? То есть можно хоть как-то подшаманить чтобы было более менее видно что лежит в контейнерах. Спасибо.

Я бы шеред использовал, если работают больше одного

Либо все должны через методы владельца обращаться, если юник

Принтфами дебажь.

Кажется, что лучшее, что можно сделать, — законтрибьютить принтеры для контейнеров, которые используете

То есть какого-то решения для этой проблемы нет?

неа. тоже самое касается и других контейнеров из других библиотек. только писать преттипринтеры и их использовать. Как, например, это сделано для того же Qt

Спасибо огромное.

Ну можно еще в gdb делать cast сырых данных в структуры

Но это довольно муторно делать для коллекций