Тама то многажды раз здесь изъезженная)) 

На пальцах:
У класса есть данные (свойства - Property) и ссылки на другие классы (концы ассоциативных связей - AssociationEnd).
Обычно, данные копируются, а ссылки - нет. Это не всегда так, но опустим эти случаи из рассмотрения.

Концы ассоциативных связей могут быть как частью класса, так и находится в не его. На выбор программиста.
Когда концы ассоциативных связей  находятся вне класса (отдельный менеджер связей, отдельная таблица соотношений в БД и т.п.), это может быть не таким эффективным (обычно), как хранение концов ассоциативных связей в самом классе.

Когда концы ассоциативных связей являются частью класса, имеет смысл разделить его на две функциональные части:
1. Часть для работы с ассоциациями.
2. Часть для работы с данными.

C++ (Qt)
struct Data
{
     // bla bla bla
};
 
class Item
{
    Parent m_parent;      // например, Parent = Item *
    Children m_children; // например, Children = QVector< Item * >
    Data m_data;
 
     // bla bla bla
}
 

Как таковые Item'ы не копируются, а создаются на основе данных другого, с указанием новых ассоциативных связей.

Igors
ssoft говорит вам о том, что мухи - отдельно, котлеты  отдельно.
Отдельно данные, отдельно дерево.
Если надо копировать дерево, то сделайте копирование дерева.
Если надо копировать данные, сделайте копирование данных.
В целом, операция копирования подветки - самостоятельная операция, она же "выделение поддерева". Это нормально, что после копирования ветка будет без родителя (откуда ей, собствнно, знать, что вы хотите с подветкой делать дальше?).
Если уж так не хочется делать две строки
ну сделайе опциональный парметр нового родителя, если уж паттерн такой частый

Но я бы шел по пути вумных укзателей и назначал родителя руками, ибо нагляднее:

Но это синтаксический сахар и вкусовщина, способ выше с newParent ничем не плох.

Не очень понял что имеется ввиду под "старым добрым". Отказаться от контейнера и добавить члены m_prev/m_next, что ли?

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

Чот быстро заглохло=)

Вывод неверный=)


Увы.

Не обязательно

Хмммм, нам надо как-то передавать нового парента, блин, как же это сделать, не передавая нового парента?


Начнем издалека. Дерево всю жизнь реализовывалось на указателях. Не потому что какие-то ограничения, а потому что симметрия - это красиво, если вы храните указатель на парента то красиво (симметрично) к нему хранить указатели на детей. Удобно, красиво, но не обязательно. Если хотите сделать дерево на value-based классе - вперед, будет домашнее задание=) Можно даже от указателя уйти и хранить std::ref. Удачи правда в обновлении парента у детей при ресайзе вектора, но о5 же, всё в ваших руках=) QList упростит задачу.
То есть, зафиксируем - мы меняем vector<Item> на vector<std::unique_ptr<Item>> просто ради симметрии и удобства (ну и стабильности указателей на парента).
Далее, вы, вероятно, читали опус про value-based классы. Деревянный айтем не может иметь конструктора копирования ровно как не может его иметь виджет или std::thread (что должна делать копия треда? запускать функтор заново? продолжать в том же месте?). Причина очень проста - после "копирования" вы не получите копию. Например, если у айтема есть "пропертя" int row, то она будет отличаться даже если парент остался тот же. В самом деле, не могут же два айтема лежать в одной ячейке вектора? В вашем случае, вы хотите менять парента, что противоречит идее "копирования". Копия должна быть идентична оригиналу. Именно потому, что вы хотите получать "похожий" объект (но не копию!) конутруктор копирования нужно запретить (иначе будет очередной std::auto_ptr с сайд-эффектами). И тут не важно, используете вы value или pointer-based, метод clone() делать придётся (ибо клон похож на оригинал но отличается от него).

Итого, изменений два по двум причинам:
-указатели ибо красота и стабильность парентов
-clone, ибо копия не имеет смысла

На данном этапе есть вопросы?

Что значит "внешней"?

Как раз таки все эти новомодные цацки нужны чтобы код был читаемый а не как ваша каша с непонятным владением.
Мув явно говорит - владение передали дереву. метод слон(парент) - плохой, негодный метод. Я лично напишу две строки - выделить поддерево (слон без параметров) и вставить в поддерево в новое место (item->append/item->insert).
юник_птр избавляет от богомерзких qDeleteAll, по это то же самое, что "vector<Item>"
Все ваши проблемы что вы не можете разобраться кто чем владеет.


А ничо что граф и дерево - разные структуры, ммм?
Если вам не хватает дерева (хотя судя по всему хватает), ну давайте обсудим, как реализовать граф.
Ну и о5 же каша. У вас есть данные. Данные отдельно. Их можно положить в дерево. Их можно положить в граф. Зависит от того, что надо сделать. Нужны множественные связи к паренту? Юзайте граф. Не нужны - юзайте дерево.
Да, дерево - частный случай графа, но зачем мудрить, если дерева хватает?

КОТоВасия с мувом нужна для того, чтобы было видно, кто кем владеет. В вашем исходном примере с value-based таки каша. С одной стороны, айтем владеет детьми. С другой, корневой айтем "сам по себе", но не совсем - им владеет тот, кто его хранит. При этом все айтемы могут ссылаться на парентов. Вот мы копируем айтем это что же, у всех детей надо паренты менять?

Зайдем с другой стороны.
Вот есть сишный код
Это дерево? Или одиночный элемент дерева? Могу я удалить айтем? С одной стороны, QObject учит что можно. С другой, не посмотрев в код айтема (ну что там автор намудрил) не разберешься.

А теперь следите за руками
ВНЕЗАПНО, unique_ptr на айтем становится самотоятельным объектом ДЕРЕВА а не отдельным элементом (айтемом)
ВНЕЗАПНО, ObserverPointer на айтем становится элементом дерева, а не деревом! Типа псевдо-"итератор".

Где же магия? Как же так вышло, мы заюзали какую-то "вумность" и внезапно образовались абстракции - и сущность "дерево" появилась и "элемент дерева".

clone - слоне, слон.

Ну сделайте шаблонное и\или виртуальное дерево, в чем проблема? Ах, проблема в том, что элемент дерева и дата у вас в голове - одно и то же и представлелы одним классом.

Тогда зачем создавать тему про дерево, если вы хотите реализовать граф?? ВНЕЗАПНО у вас задача меняется.