Примеров итератора с доступом на чтение я много оставил, а пример
модификации дерева только один. И тот я сразу забыл перевести на
итераторы (range-based for loop).
Т.к. проход теперь не по вектору (он давал экземпляр умного указателя),
а по обычному указателю (собственному прокси, если точнее), то узел
разрушался уже в процессе его отключения от дерева. Добавил удержание
ссылки в сам `unlinkParent()` (ну, нам действительно может быть нужно
только безвозвратное удаление поддерева) и пример в `main.cpp` расширил
и прокомментировал.
Решил обойтись простым ~~советским~~ статическим методом:
template <typename T>
class FabricMixin {
public:
template <typename... Args>
static std::shared_ptr<T> create(Args&&... args) {
return std::shared_ptr<T>(new T(std::forward<Args>(args)...));
}
};
Ну ладно, он не так просто выглядит на первый взгляд. Но, по сути, всё,
что он делает: параметризует метод типом возвращаемого указателя, и
передаёт все аргументы как есть в конструктор заданного типа. Решил
сделать так, чтобы не копипастить тело конструктора. Ну, вдруг я,
например, трассировку туда добавить захочу. Правда, есть недостаток у
такого решения:
class SimpleNode : ...,
public FabricMixin<SimpleNode> {
friend class FabricMixin<SimpleNode>;
Не очень удобное подключение: а) нужно внести по крайней мере две
строчки; б) автоматически самого себя параметром шаблона передавать
нельзя.
Вносить этот метод в `BaseNode` (или около) не хотел, чтобы не
пробрасывать оконечный тип по всей иерархии. Да и от указанных выше
проблем он не избавляет. Зато можно будет относительно безболезненно
выпилить этот класс, если ему подвернётся достойная замена.
Т.к. в основном меня либо интересует создание/удаление объектов, либо
нет. Смысла объединять это логи с другими логами объектов каждой
подсистемы я не вижу.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Сергей Маринкевич