Комментарии 4
Спасибо.
Теперь по теме: немного не понятно, в случае если мы создаем копию и потом ее лениво обходим, в чем преимущество? Проще фильтрация? Эффективность-то получается как в старом коде, если не хуже.
Если я верно понял вопрос, то имеется ввиду контейнер, который содержит указатели на все узлы дерева. Так работает настоящая реализация QObject::findChildren и первичная реализация без использования сопрограмм.
Такой подход имеет смысл, если дерево может быть перестроено в процессе по-настоящему ленивого обхода. В случае использования сопрограмм, неявно будут сохранены ссылки на некоторые узлы. Корректнее будет сказать, что ссылки на контейнеры, которые содержат дочерние элементы узла. Если они "подвиснут" может случиться беда.
Это довольно редкое явление, но внутри Qt я знаю пару мест, где так может случиться.
Но и даже в случае ленивого обхода уже созданного контейнера, который содержит все узлы, есть польза. Если коротко, то мы получаем более чистый и гибкий код. Эффективность там ничуть не хуже чем в старом коде.
В репозитории на гитхабе есть тесты, которые можно погонять.
Копирование контейнера обычная практика в UI библиотеках. В основном это применяется там, где во время обхода вызываем пользовательские обработчики, т.к. нередкая ситуация, когда в обработчике пользователь добавляет/удаляет виджеты. После этого естественно, все итераторы оказываются невалидными.
Ленивая реализация обхода дерева дочерних элементов класса QObject