Вообще-то unique_ptr на то и unique что он НЕ scoped_ptr и его можно (и нужно) передавать вызывающему:
Да, это не для "эстетов", которым лучше бы написать одну строчку, покороче, но зато с десятком сайдэффектов.
Впрочем, для эстетов тоже можно:

Это почти ничем не отличается от

Что меняется-то? Разве были какие-то ограничения на способ хранения parent/child ? Это читателю букваря/std необходимо чтобы все укладывалось в прочитанные рамки, а если нет - все, "плохая задача!!". Зачем Вы повторяете эти глупости?  
[/quote]

Ну давайте теперь прот граф поговорим. Итак, графы бывают направленные, ненаправленные. Ребра графа бываю взвешенные и невзвешенные (или как они там называются, крч, когда есть веса и когда нет весов). Вам каких отсыпать?
Далее, есть разные реализации. Можно "на айтемах" (видимо, вы это подразумеваете) - каждая нода хранит ссылки на соседние ноды. Эта структура сложнее, чем дерево, так как из-за циклических ссылок нодами владеть должен объект графа, а не сама нода - придется делать обертку, в ней хранить "хардлинки" на вершины (ака юник_птр).
А не хотите граф на матрицах или списках? Например, невзвешенный неориентированный граф очень красиво делается через вектор булок (ака QBitArray) - делаем "матрицу" N*N где N - кол-во вершин, в ячейке i,j булка говорящая о том, есть ли такое ребро. Этот граф оч хорошо жмется по памяти - в 1м байте хранятся аж 8 ребер.
В случае, если есть веса, булкой не обойтись - придется хранить вес. Размер матрицы увеличиваетсяв 8-16-32-64 раза (в зависимости от размерности весов).
У обоих матричных решений есть минус - если ребер мало, а вершин много, то много места пропадает на хранение false (или нулей).
Это можно решить "списками" - хранить массив вершин а в нем список (или другой массив) вершин, до которых можно дойти напрямую. Тут сложнее удаление ребер, кроме того, больше аллокаций (и, возможно, менее кэш-френдли).

Чуете, да? "Универсальный" граф вы не напишите - если надо искать путь в графе, то вам подойдет одно решение, если надо проверять наличие ребра, то другое.

Меня удивляет что ситуация которая у меня встречается на каждом шагу, для Вас выглядит совершенно незнакомой. Ну хорошо, рассмотрим пример из моей практики

Два 3D объекта (A и B) могут быть связаны разнообразными "constraint(s)". Это значит что какие-то трансформы объекта A (обычно позиция и поворот) вычисляются автоматычно на основании взаимного положения A и B. Напр задан "AutoLook" constraint, значит A должен "смотреть на B", т.е. автоматычно поворачиваться к нему лицом (ось Z направлена на центр B). Напр юзер передвинул B, и А повернулся к нему.

Это "отношение" не уникально. Объект A может иметь сколько угодно других constraint напр с объектами C и D и даже с тем же B, и тип может быть тем же AutoLook. Хотя практически число связей редко превышает 2-3. Отношение имеет параметры, часто "вес" чтобы комбинироваться с другими. Объект A может быть парентом B или его чайлдом, могут быть и любые другие отношения между теми же A и B.

Можно решать это в лоб - хранить в A указатель на B и наоборот. Точнее вектора указателей, т.к. связей может быть > 1. Ну дальше надо по меньшей мере разрывать эти связи при удалении A или B. Также consraint - всего лишь один из возможных связей.

Предложите общую конструкцию которая здесь (давно) назрела


 

В общем случае - нет, в конкретном случае выше - да. Как-то Вы зациклились исключительно на "владении" как будто других дел нет 

Если бы все вокруг решали вашу задачу, то кому-то бы не осталось работы.
Я достаточно часто меняю конторы и везде задачи разные. Если вы в течение 10 лет пилите одно приложение, то не удивительно, что у вас вызывает удивление что никто не реализовал граф

Ставки повышаются .


Мне одному кажется, что уже в первом предложении было описано решение?

Что такое "графика" - не знаю, но до 3d там еще далеко, это простая математика в рамках общей культуры инженера

Что отвечать-то если Вы начали молотить не в тему?
Задача та же самая (деревянный айтем), никак она не менялась - ни внезапно ни постепенно. Цель - построить структуру для доступа к данным, парент знает своих чайлдов и наоборот. Традиционно это делается членами класса. А в общем случае это граф. Напрашивается напр такое

C++ (Qt)
struct  CTreeItem : public CGraphNode {
  CTreeItem( CTreeItem * parent );
  virtual ~CTreeItem( CTreeItem * parent );
 
// обертки базовых вызовов CGraphNode
  CTreeItem * GetParent( void );
  int GetChildCount( void );
  CTreeItem * GetChild( int index );
  ...
// data
  QString m_name;
  int m_flags;
  ...
};
 

Теперь базовый класс возьмет на себя заботу о хранении парента и чайлдва. Как он должен выглядеть? Попробуем пойти по пути наименьшего сопротивления

C++ (Qt)
struct CGraphNode {
// data
  QVector<CGraphNode *> mArcInp;  // входные ребра (чайлды CTreeItem)
  QVector<CGraphNode *> mArcOut;  // выходные ребра (парент CTreeItem)
};

Реализовать это не составляет труда. НО мы взялись делать "в общем виде", стало быть должны хранить всякие-разные зависимости (не только деревянные). По этой же причине "матрица графа" не катит.  Возможно будет создано еще ребро(а) никак не связанные с деревом (см пример с consraints). Как тогда мы будем искать парент/чайлд для нашего айтема?

Как видите тут есть о чем поговорить - было бы желание

Здесь не идет речь ни о каком "управлении" или "владении". Мне нужна структура данных для хранения связей которые могут быть очень разнообразны. Необходимость управлять, шарить, проверять на цикличность и.т.п. возможна, но вот это как раз та самая "другая задача".

А Вы читаете? Выше я писал что объект может быть повернут лицом к N др объектов которые даже могут повторяться, и это дает разумные рез-ты.

Если "ничего не нужно" и " все ни при чем" - то как тогда пересчитывать-то? Да, мы можем хранить указатели на объекты в экземпляре AutoLook - но как к нему достучаться если юзер двигает A и/или B ? И как удалить AutoLook  если удаляется A или B? И.т.п.

Сonstraint сам по себе - не 3D объект, а действие между парой таких объектов. Пихать сам экземпляр AutoLook в дерево - пока об этом разговора не было, но это не лишено смысла. Почему бы не хранить не только "факт связи" между A и B но и параметры этой связи (в данном случае указатель на AutiLook)?

Ну это я тоже знаю Потом неожиданно выяснится что Вы "что-то предлагали", а я никак не смогу вспомнить а что же?